The snmpconf (SNMP Configuration) working group meet on Tuesday and Thursday
March 28 and 30 during the 47th IETF. Below are the minutes of those
meetings. Special thanks go to Carl Kalbfleish and Shawn Routhier for taking
a comprehensive set of notes during these meetings. Please also note that
the presentations briefly described in these notes will also be published in
their original form. These notes are a bit longer than usual since much of
the question and answer discussion was not removed from these minutes in
order to capture as much of the meeting as possible. This single set of
notes documents the 3 different sessions the WG group meet in order.
The first session began with a review of the agenda which included:
Agenda Bashing
Administrivia
Overview of Approach
break
Document Status - editors
Work to be done by the teams
Q&A
The proposed agenda for the Thursday meeting was:
Review of Tuesday
Policy based management MIB
Technology specific (Differentiated Services) policy MIB
Best Current Practices Document.
Dave Harrington began with a review of the three main deliverables of the
Working group:
A Best Current Practices document on SNMP based configuration
A MIB module to be used to facilitate policy based configuration
A MIB module specific to policy based configuration of differentiated
services.
Proposed dates for two interim working group meetings were announced with
suggested locations:
May 17,18,19 interim meeting Boston
June 28-30 San Francisco
The goal of these meetings is to facilitate delivery of drafts for the
expected July 14th ID cut-off in preparation for the July IETF Meeting in
Pittsburgh. Dave Harrington then introduced the editor teams currently
working on the documents:
1. Capabilities MIB Module - This has been renamed the Policy MIB
Module. The editors are Steve Waldbusser, Jon Saperia and Thippanna Hongal.
2. Differentiated Services Policy MIB Module - The editors are currently
David Partain and Harrie Hazewinkel.
3. Best Current Practices Document for SNMP-based configuration - The
editors are Mike Macfaden and Jon Saperia.
The mailing list information was presented and is:
General Discussion:snmpconf@snmp.com
To Subscribe: snmpconf-request@snmp.com
In Body: subscribe snmpconf
Archive: snmpconf-request@snmp.com (index snmpconf in body)
Jon Saperia began with a presentation that described the general background
and goals of the working group and an overview of the current SNMP
architecture and how SNMP based configuration fits into that architecture.
The benefits of this integrated approach were also described.
The general architecture includes a policy MIB module used by systems to
advertise their capabilities (such as support for differentiated services)
and the types of roles they support such as interfaces that carry traffic
from executive offices. The working group is also undertaking the
development of a Differentiated Services Policy MIB Module as an example of
how such a module can be combined with the general Policy MIB module as a
means of aggregating configuration commands in complex technologies. It is
optional and up to the various technology experts to determine if such a
module is necessary. These two modules, the Policy MIB Module and the
Differentiated Services Policy MIB module (which is used as an example for
further work that other WGs interested in other technologies may use) are
designed to work with the many, many thousands of MIB objects currently
defined. These new MIB modules are 'layers of abstraction' on top of the
basic objects which have been and will be defined.
The presentation continued with an overview of the steps for configuration
that would occur in a system with these capabilities:
1. The technology specific policy subsystems would register with the
policy module their capabilities. They are expressed in terms of policy type
and subtype MIB Objects.
2. The manager(s) would then be able to determine system capabilities (web
server, vpn support diff serv, mpls, etc.)
3. Managers define roles and associate them with specific instances in
specific devices.
4. Managers send policies to managed devices such as: traffic from
interfaces for executive offices need to be marked such that they are given
preferential service.
5. Managed devices evaluate the policy filter and policy action MIB
Objects (the two parts of a policy sent to a managed system) to determine
where and when the policy is applied.
6. The technology specific module sets all necessary values to the
instances which have evaluated as belonging to 'rule' expressed by the
policy filter in the policy MIB Module.
Randy Presuhn asked: How does one know the interface is an exec type when
things are evaluated.
Jon Saperia: Indicated that such information would need to be marked, most
often this would require human intervention.
7. A technology specific policy MIB module may not always be required and
the general Policy MIB Module may be able to fully express the details of
the action to be performed without further expansion in a technology
specific policy MIB Module.
8. The management software monitors usage and status to refine policy or
verify changes.
The meeting continued with a presentation of the Policy MIB Module by Steve
Waldbusser.
Policy based management provides a method of aggregating management
operations and applies them globally to all elements that share certain
characteristics.
Policies are in the form of
if (element has certain characteristic) (then do something)
Examples
if (it is fast ethernet and is a trunk) then (apply full duplex mode)
The Framework:
Policy specification exists in a policy server
SNMP is used to move policy to the Policy MIB Module
How the policy is instantiated in the managed system is implementation
specific.
A policy is a filter and action pair as described above. The intention of
this architecture is to leverage extensive MIB based infrastructure. Filters
can use objects to determine what to do. Actions can use objects to cause
the action to be realized in the managed system.
The Policy MIB Module requires:
1. The Core Architecture
2. The policy table that contains objects for communicating policies
3. Policy filter language.
4. SNMP based support infrastructure
The Policy table contains:
- filters and actions would probably be octet strings
- description - more information about the policy these descriptions which
can contain operational 'clues'.
policyMatches - number of current matches, useful for debugging
Policy filter language
need to define a way to express a filter and action
Other tables/features in the Policy MIB Module: role table, capabilities,
time.
About Roles: Some necessary concepts for policy have never been described in
MIB objects so we need to add them ourselves. Roles can be political (is
exec, outside contract), financial (gold contract), legal (lifeline) or
geographical (California, insecure conduit), or engineered (backup, trunk).
A table is required for the down load of this information, thus the
roleEString table.
Capabilities Table: The capabilities table allow managers to know what types
of policies or configuration operations are supported in the managed
elements.
Time: policies may need to be executed only at certain times so we need time
controls. We need to provide two views of time: globally consistent (UTC
time) and local "business time" (MF 9-5 local time).
Operational Considerations:
- Policy creation: need to allow an engineer to debug a policy
- Policy actions can be debugged in a lab (may be provided by a vendor or
other as a library of commands)
- Debugging of policy filters consists of ensuring that the filter selects
the intended set of elements. (need to provide some way of getting feedback)
- Need to see where a policy would be executed - table that shows where a
policy is executed.
Advantages of the approach: built with existing infrastructure and tools,
leverages existing MIB Modules, flexibility, complete architecture, includes
operational tools.
After the presentation by Steve there were a number of questions and
answers. Note that some of the questions are not really questions but
statements of opinion. They are included here as questions (Q):
Q. SNMP can be used to communicate a policy language to device. Many ways to
do such communication, have the requirements for real time, reliability,
etc. been considered?
A. These have been thought about but it is a longer list and should
be taken to the mailing list. RFC1270 may have some helpful information.
Q. Have they thought about secure source of time? Policies may be pushed
early and scheduled for activation at other times. This may require secure
time on the local system.
Q. Examples seem to be interface based, but much of the policy
questions would be based on other items such as class or type of traffic.
A. This is simply an artifact of the examples Many things would be
available, in the particular example there would need to be a traffic
classifier.
Q. Policy may need to be applied to something such as all traffic to/from an
IP address. Policies seem to attach to something in a device. We may want
to attach policies to other items such as IP addresses which will go across
larger structures (entire networks).
A. Confusing taxonomy: in this particular case policy is being overloaded.
Q. What is the difference between policy MIB and the PIB
A. <no answer given> [Editorial comment from Jon Saperia who edited these
notes - while both items are still in development it is difficult to make
exact comparisons especially when which PIB we are speaking about is not
specified. In general, if one thinks of the Policy MIB modules under
discussion as providing an aggregation of configuration commands, then there
is probably some similarity. The Policy Module accepts aggregated commands
that are expanded locally on the managed element. This is what happens when
a policyFilter is expanded to provide all the instances to which the policy
action is to be applied, and the technology specific Policy MIB Modules
expand the configuration command (policyAction) of say provide EF PHB to a
particular DSCP value, to the many parameters needed to cause each interface
selected to provide the desired behavior. Not that the Policy MIB Module
also contains the expression of the Roles and Capabilities of the device
which in a PIB environment would be conveyed by other means.]
Q. Randy: jump up several layers of abstraction talk about configuration
mgt. but this isn't configuration management, these are aids for
configuration tools. For example this doesn't give any sort of version
control of configuration mgt.
A. Steve: different view of configuration management, we are providing the
tools for helping out with configuration
Follow up question by Jon: would provisioning be a better term? Randy said
no.
Q. Some items that are general vs. some items that are unique per system
how will they be handled
A. Roles (which are handled by humans) can be used to handle such items
there may also need to be consistent filters etc. Such a scheme may result
in an explosion of roles which could be expensive and so needs to be
controlled.
Q. Does this mean you will need to configure something to configure
something (configuration role to configuration parameter)?
A. Well yes, but you would only need to configure the role once and
this may give you other features.
Jon: clarification: For those items that may be easy you can just touch them
directly rather than go through the role and rules. [Jon's added editorial
clarification - this means that for simple configuration operations like
changing an IP address, it is not necessary to use any of the mechanisms
discussed thus far. It is still possible to use basic SNMP set mechanism to
change any instance specific objects desired with no additional overhead.]
Q. How does this connect to the policy working group.
A. This work attempts to use the work in the policy WG as the base info that
would be fed into things.
Q. The filter/action is similar to some of the work in the policy WG
but not exact. will this be a problem. They are not meant to
be direct connections but are meant to be connected.
Q. Configuration management is challenging task for ISP . What to keep track
of what the object should look like vs. what the network is. By using MIB
objects as storage are you not seeing what the network is, rather than
storing what it should be. The aggregate that they are probably using are
similar but are not being used in real time?
Take to mailing list: How to deal with large batch of objects, How to store
information about networks, How to capture design rules for network
Q. Set the record straight about the meaning of policy. Doesn't think that
policy is an aggregate of configuration. Policy framework talks about
abstraction rather than aggregation. By using an improper definition for
policy this may be different than policy framework. Suggestion that there
are flaws in the scheme, the discussion focused on the little things. But
we need to discuses the big things. SNMP has a known feature set that may
not be proper for use as configuration mgt. Attempt to push to much
information and capability down to the device. Reliability, fault tolerance
Bad thing for the device to know to much of the policies, as this may
require too much update.
A. Take to the mailing list.
The next presentation on the agenda was from David Partain on the Diffserv
Policy MIB Module
Current status: A skeleton that still needs to be filled in and input from
the community is desired.
Input to our effort has thus far come from: PIB work in the rap and Diffserv
WGs, goals are similar to the PIB work but without using a new framework
Goals of the Diffserv policy MIB module:
- network-level policy based configuration of elements supporting diff serv
- to provide a level of policy abstraction above the diff serv MIB module
mapping tables
- diffserv configuration template - tables to map between the goal of
policies and the implementation of configuration an addition to the table
won't cause changes, but an use of that policy will cause the configuration
to be updated.
Input to and output form the diffserv policy MIB module:
- Manger may speak directly to the diffserv MIB, diffserv policy MIB
module may be viewed as similar to PIB
Q. Work done in policy group is a high level model of how things
should work.
A. Two different middle layers with upper and lower systems the same
in concept.
Believe that the IETF should examine why the two are different
should find the conceptual differences between the PIB and
the policy MIB module as this will give us good information
for solving the problem
Agreement from Dave that this is a good idea and that we should
try to reduce the difference and hopefully come up with a single
solution.
David Perkins: comment to let the market decide.
What's to be done
- what are the abstraction needs
- understand what can be or needs to be abstracted
from the diff serv MIB
- relationship with the policy based management MIB
- put meat on the skeleton
- alignment with other WGs
Input from the community desired
- snmpconf WG input
- diffserv, policy, rap
- diffserv abstractions
- policy based management application developers
Upcoming Milestones
- post draft during next week
- collect WG input
- revise and post draft by Friday before interim meeting
Q. Should Relationship between multiple MIB modules be standardized?
A. Interrelationships will be via shared indices and probably not be
full blown interfaces.
Q. Has the overhead been calculated for how much this would cost.
Concern that this will be expensive. This may be caused by
a misunderstanding of the policy and should be taken to the list.
Will there be a space crunch or will this thrash?
Q. Will it be possible to have conflict between the MIBs
A. Yes
Q. Will there be conflict resolution.
A. Yes, there doesn't seem to be any around it.
The next presentation was on the Best Current Practices Document by Mike
Macfaden:
Presentation Topics
- review problem statement
- goals
- requirements: user vendor
- review Best Current Practices draft
- review further work items
Goals of BCP:
Document existing knowledge and techniques which demonstrate effective
use of the SNMP framework for configuration.
Requirements/User:
- secure authenticated access
- fine grained access control
- standards based
- integrated view of configuration status and diagnostic info
- the configuration method should not obscure what is being configured
The presentation continued with a discussion of service provider
requirements and the basic outline of the BCP document with some example
suggestions.
Tasks to be done for the Document:
April
- collection of info and best current practices on the mailing list
- produce new draft for upcoming may meeting
May
- revise based on feedback compiled for 17-19 May
June 28-30
- revised based on May meetings and further development
Q. Seems that the best current practices goes beyond configuration is that
correct?
A. No. It is not the intent to go beyond configuration but there may
be connections elsewhere, the particular question asked about notifications
which might get involved as part of a configuration change notification.
Q. Does [this work] include network wide configuration issues as well as day
to day type of things.
A. Yes.
Q. COPS has a clear ownership for a given policy or area, having multiple
managers will make this more difficult do we want to discuss it.
A. The design team believes that multiple managers and interfaces
will be useful/required.
The meeting now turned to setting up the agenda for the Thursday meeting
which will look at some of the documents in more detail. The order will be:
- BCP
- diff serv policy MIB module
- policy MIB module
Thursday March 30th Meeting.
The meeting began with a discussion led by Mike Macfaden on the Best common
practices document. The outline was reviewed and a call for contributions
was
made.
Trying to get this done in a month or so, April will
be busy (hopefully)
Document is still young and looking for contributions
BCP outline
Tenets
must deal with Murphy's effects, the network may be unstable at times
even while configuration is happening.
Undocumented defaults are bad.
MIB design - the following are some example issues about MIB Module design
that are targeted for inclusion in the BCP.
Large amount of power available in SMI, must select the
proper abstraction - may be able to use some metrics to
determine if the abstraction is correct - number of
objects to change, rate of change of those objects
higher level error information at the application level is helpful and can
be contained in MIB objects. Information about this should be in the BCP.
Include some support for diagnostics to help debug things
trap throttling and higher level decisions to send/not send traps
persistence - how the various protocols will play together
with objects tagged as read-only etc.
Other general problems/benefits of having multiple management interfaces
Management system design
Need to show examples of things like AC and sysOR table such that
agents do them properly and that managers know what they can do
do with them and how they might do so.
Possibly try and connect the fault system with the configuration system
such that folks (users) may be able to understand that "this section
of the net is under construction and may be less than smooth"
Comments:
GWW - any clarifications that we find should also be reflected back
in the base docs that cover that area.
Q. Why is policy related stuff in the doc
A: As we add network wide management we may need more information and
practices so that users have a general understanding of how to perform these
functions with SNMP.
There were multiple comments about usefulness of the work.
Unknown comment- Policy is an overloaded term. Suggestion that as we move
forward we more clearly define policy high level description of the policy
stuff policy vs. policy rules vs. device stuff.
Bert - Terminology is being handled in other WGs probably part of
the policy framework WG (and charter).
The next presentation was on the Differentiated Service Policy MIB Module
and was lead by Harrie Hazewinkel. Rather than using the Differentiated
Services MIB Module which is very complex, Harrie created a wwwPolicy MIB
Module as a way of presenting the relationship that exists between the
Policy MIB Module, the Technology Specific Policy Modules such as the Policy
MIB Module Differentiated Services and the device/instance specific MIB
Modules.
Example scenario uses policy MIB, wwwbwpolicymib and wwwbwmib
- wwwbwmib would probably already exist as part of other work.
- policy MIB includes the filters and actions
- The wwwbandwithpolicymib subsystem registers it's capability with the
capability table of the policy MIB Module
- the manager can then read the table and start configuring the wwwbwmib
table and the various roles that may exist (this is defining the services
and associating as necessary)
- The policy table then is configured to map things and the wwwbwmib is
updated as necessary
Q. Andy - without some more details this example doesn't allow
for much discussion.
Unknown - perhaps we should use OIDs rather than octet strings
to allow for better filtering.
A. Dave Partain - Understands that this isn't most useful but this
is mostly trying to show an example of sequence of events and
the connections between the tables.
Many people still have some difficulty understanding the example
of how things should work, etc
A. Randy - was able to understand it (he thinks)
Q. What happens if somebody adds entries to the device table after the
policy has been "activated" should such new rows be subject to the policy?
A. Dave Partain - need to look at that issue - this is all part of allowing
multiple interfaces/managers and we may need some extra work/objects to make
it function (timestamps etc).
Q. Randy - If we are doing configuration automation then the new objects
wouldn't need to be updated. If we are doing policy automation then the new
object would need to be updated. We need to be clear on what we are trying
to do.
Q. Andy - Another vote for understanding the example, with a suggestion
to try and keep things simple and not get bogged down in the details.
Q. unknown - this is one way to give a standard way to access a bunch of
device specific information.
[Editors comment - The above question is important since it correctly
captures an essential component of policy based work. That is that different
levels of abstraction are needed. In the SNMP environment this concept can
be powerfully used since access based on a user's role (such as
administrator) can be controlled quite well. For example a less 'skilled'
individual may be able to turn a policy on and off as required. This would
require access only to the Policy Module. A more 'experienced' individual
might be given access to the technology specific MIB Modules such as the
example WWW Policy Module Harrie presented above. The most skilled might be
allowed to access the device specific details and modify them. Examples
include the Differentiated Services MIB Module currently under discussion in
the Differentiated Service Working group.
unknown - multiple interfaces may lead to difficulties
<that is one item to be dealt with both in technology and admin>
Q. Dave Perkins - no magic in SNMP, SNMP and MIB modules are just one way to
move information the magic occurs in the other functions as they try and do
something with that MIB data.
Q. Jeff Case - identified one area that needs work, when multiple layers are
able to manipulate the same data via different routes how do we choose which
setting "wins" is it last one wins or higher authority wins or some other
option. This also includes such questions as what happens when a policy has
caused a change in lower layer tables - should the table be reverted when
the policy is removed (or expires) etc.
Q. John S. - One approach that wasn't mentioned previously - some other
groups couldn't see a way to deal with the multiple manager problem.
They used a new object to specify who has control
Q. Jeff Case - this doesn't solve the problem, it simply moves it. What
happens when control changes hands - should changes revert.
Q. John S. - a solution to this problem may be intractable and at least
should be in it's own RFC
Q. Jeff Case - if we only allow them serially then we must disambiguate
rules during change over if we allow them in parallel then we must
disambiguate rules in real time.
Q. John S - should this be a separate work area
Q. Jeff Case - must be careful to avoid biting off too much and should try
to solve the problem that we understand and that we can. Expansion in the
future would be good.
Q. Andy - Any solution will need to cover the multiple manager interface
and multiple layers.
Q. Randy - This discussion may be pushing to attempt to much too soon, doing
some of the other steps first may make solving this type of problem more
tractable.
1) the current work is doing well at capturing what you want your
configuration to be
2) the next step should be to figure out what you currently have
3) the third step would be to make the current configuration match what you
want
4) this discussion seems to be going beyond the 3rd step.
Q. Jeff case - sounds like Randy is discussing new configurations available
on reboots.
Q. Randy - that is not what I meant, restate of his points above
Q. Dave Partain - disagrees about where we are starting and thinks that
we are starting at the early steps that Randy mentioned
Q. Jeff Case - difficulty in exceptions - we want a general policy but
with some exceptions the difficulty is how to define when the exception
should be corrected and when it should be left as is.
Q. Dave Perkins - some information/objects may only be available via certain
interfaces, some from CLI, some from SNMP etc. A policy manager may need to
be able to access multiple interfaces
Q. Unknown - The policy description is good even if it isn't used to drive
the object setting directly.
Q. Dave Partain - will try and update things to be a little more "real"
The final discussion of the day was lead by Steve Waldbusser on the Policy
Based Manager MIB Module
- We are building an infrastructure
- We can use small building blocks, e.g. use MIBs (which may be already
available).
- need to add some pieces
- role table -
- capabilities table - used to allow managers to understand what they have
to work with.
- time objects -
Policy Table:
- simple SNMP table with octet strings for filters and actions
- also includes description string, this string may be carried along
through translations to more device/mechanism specific
Q. Randy - Does the expression evaluation happen at a point in time or
does it cover all objects?
A. It covers all objects.
Q. Are there constraints on objects in policy actions?
A. There are no constraints. A policy action can touch any object it
wants/needs, at least in theory. The two of these may lead to cycles where
one policy action cause the firing of another policy filter/action. Is
there any method to keep this from being infinite (no, this problem doesn't
seem to be of major concern).
Q. We may not have a problem with the multiple managers, if we
do we can add owner strings or some other feature to prohibit
this function.
Q. Randy - may need owner strings to allow VACM to work with a
reasonable number of entries
Q. Andy - conflict resolution, who is responsible for finding conflicts
in the table?
A, Steve - first need to start determining what conflicts are real and some
work is needed here.
Q. Andy - will policy matches be tractable or will the entity need to spend
a lot of time to do the updating.
Q. Andy - need to formalize the octet strings for filters/actions
(agreement)
Q. Jeff case - does conflict resolution need to be handled for both policies
from the same source or different sources, conflicts are not necessarily bad
as long as there is a precedence order to resolve them
Q. Andy - but we don't want the device spending all of it's time resolving
them.
Q. John - describe some of what happened in the policy groups when they
looked at some of these problems, currently work in the policy group
on information model and schema but not on the language
Q. Steve - details of the language are not important yet, figuring out above
that what sort of conflict resolution we are going to use is.
Q. John - need to get some of the requirements before trying to write a
language
Q. Randy - some of the language type issues have been solved in ISO/ITU land
several years ago and isn't necessarily that difficult. Is not sure that we
need conflict resolution, but we would need to be careful about how
often/when we do filter checking and actions.
Q. unknown - suggestion to leverage the work done in the policy group
especially for policy servers which can be gotten from elsewhere.
Q. unknown - why is policy stuff in SNMP
A. Steve - this is a policy based configuration using SNMP
Q. Andy Bierman - lots of work to describe all the details, execution
environment, languages etc.
After this series of questions and comments Steve continued with:
Policy Filter Expressions
The expression details are:
- Implicit SNMP retrievals
- wildcarding
- need to avoid locking information down to specific instances
- assessors calls to retrieve data in a convenient way, small # to be
defined
Role Table:
Two tables roleEStable and roleSEtable, one is a mirror of the
other to allow the indexes to be flipped.
--
roleSEtable
Can this be used for substring matches? Parameter to choose substring
match or exact.
--
Accessor Function:
Some work is necessary to decide what sort of accessor functions we may
need and what the functionality would be.
Capabilities table:
Type defined by WG so all managers can understand them sub type allows
implementers to add more specific info.
More Discussion follows:
Question about the type/subtype tags and if the typing will remove some of
what an implementer could do.
A. This is an attempt to give some structure to the list, the example may be
a little off in specifics but does bring up the question of where one draws
the line - should Pentium be a type or should it be something more general,
should WFQ (weighted fair queue) be a type or would that be a subtype of
some other concept More work is required in this area.
Q. Andy - the sub type should perhaps be removed from this table and
left for the enterprise to put in via an augments.
Q. Andy - what about agent capabilities?
A. Steve - The agent capabilities macro is not designed for this, designed
for MIB compliance stuff.
A. Jon - mentions the technology specific modules contain some of the
details. For example in the differentiated services policy module only the
types of queuing methods supported by the device would be populated in the
table.
Q. Andy - why not find the info from the diffserv MIB
A. Steve - attempt to make it easier to figure out what other policies
may be necessary - this brings the info into one place.
Q. Dan - need to include some concept of device limitations on execution
items - for example perhaps limiting the number of rules that may be
executed at a given time which may be different than the number stored.
unknown - still need to work on levels of abstraction across all of the
work, at the highest level the device capabilities shouldn't need to be
known, this should be something that comes in at a lower level.
Steve continued the presentation:
Time
Time needs to be accessible and may need universal as well as local
three choices:
policy calendar pointer - rfc2591
accessor function
multiple MIB objects
Q. Andy - this group may decide to avoid time or may have a bunch of
discussion that has already been happening in the other groups, (note
conflict resolution becomes more difficult with time based stuff)
Q. John - there seems to be several problem areas when dealing with time
The presentation concluded with the following table:
pmPolicyDebugPETable
Operational Requirements
Table to show what policies are/would be used on elements to
allow the operators to debug things - before the polices go out
to see what would be affected - when the policy is in use to
see what is affecting things and to turn some off if necessary.
Q. Andy Bierman - seems to be moving more to policy based rather than
configuration and thinks that we shouldn't be redoing the work that the
policy groups have been doing. Wants the outcome to be modular such that
some pieces (the configuration stuff) can be used on its own.
Bert Wijnen, our AD, made some closing remarks. He indicated that he was
pleased with the lack of heated fights and with the progress in the various
groups as well as people from the various groups getting together.