Subject: Disman minutes from Minneapolis

From: Randy Presuhn <[email-masked]>
Date: Mon, 16 Apr 2001 16:37:50 -0700 (PDT)

Hi -

Here's what I sent to the secretariat...

Following my signature are the combined minutes for the two
sessions of the disman working group at the Minneapolis IETF
meeting.  Thanks to Sanjai Narain for taking notes on Monday,
and to Wayne F. Tackabury for handling Tuesday's minutes.
I've merged the two sets of minutes and tidied them up a bit.

The slides presented are available at
ftp://amethyst.bmc.com/pub/disman/ietf50/

 -------------------------------------------------------
 Randy Presuhn           [email-masked]
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
 Fax:   +1 408 965-0359  2141 North First Street
 http://www.bmc.com/     San José, California 95131  USA
 -------------------------------------------------------
 My opinions and BMC's are independent variables.
 -------------------------------------------------------

DISMAN Meeting Minutes, March 19, 2000, IETF Minneapolis

Compiled by Sanjai Narain, [email-masked]

There were three broad themes: MIBs for new alarms, Condition MIB
(every condition is not an alarm), and Alarm Report Control MIB
(how to suppress alarms from being reported). The purpose of today's
meeting was how to reconcile these themes.

The following presentations were made:

By Sharon Chisholm: "Alarm MIB requirements", "Alarm MIB" and ITU
Alarm MIB" and "Alarm MIB Slice and Dice".

By An-Ni Huynh: "Condition MIB".

By Kam Lam: "Alarm Reporting Control (ARC) MIB".

By Dan Romascanu: ??Exact title??

Randy: Do we care that other groups like Syslog, idwg are suspiciously
alarm like. Do we care.

Dan Romascanu: yes we do. Distributed systems alarm.

First speaker. Sharon Chisholm. Alarm MIB requirements.  New proposals
for alarm management on the mailing list. What is the problem we are
trying to solve?

Compliance matrix is shown. Columns are Requirement Number,
Description, Compliance.

Alarm definition: 1.6, 1.7. Unambiguously tells you who detected the
problem. 1.7: Means of obtaining ITU alarm information.

Randy: Don't want to make the subagents visible.

Audience: Randy doesn't care which subagent generated the alarm.

Randy: Not quite. I don't want to talk about subagents, OK to talk
about subsystems.

Dave Perkins: You can buy cheaply videocameras for your house for
security. Alarm condition = movement in pool area. There is more
value if for each camera there is an agent which

Randy: Does anyone have a problem with this requirement? No response.
Strong maybe.

Sharon: Historical, requirement number .4 Condition management.

Randy: Last night, things of historical interest have never been
notifications. Hence they never appear in any notification log MIB.

Sharon: Turn this into a 'yes'. Going one, going twice. Next issue is
alarm suppression (Requirement 5.1). Is anyone opposed? No response.
Several show of hands.  5.2 Severity. How much alarm suppression. Who
has a need for alarm suppression by severity? use make use of alarm
notification in my mib? Could an alarm be automatically generated?

Sharon: Don't see why not. Another real-life example.

Randy: So if I haven't built something into this implementation
that recognizes clear condition, alarm will not clear. We need to be
realistic. Is this a show stopper? We need to be confident that this
approach is useful in enough number of cases. Have I stated your case
fairly, Dave? You don't look too unhappy.

Randy: Judging by time, unless the assembled masses are desperate
for more example, this is a good breaking point, let us discuss the
Condition MIB.

An-Ni: An-Ni Huynh/Mark Stewart, Lucent. Condition MIB. Mainly for us
to understand there is an abnormal state in which an entity exists. We
want to know the current status of device. Is condition current,
transition or retired? One type of notification for OK condition.
Suppress alarm notification/reporting filtering based on level of
security.  Alarm notification is relevant to condition. What kind of
alarm type is it? We also need to know what type of device it is.
Also, is it a circuit pack, or physical port? This looks like an
ITU-T specification.

Randy: Replace alarm with "condition" on this screen.

An-Ni: Condition detection ? one of three lists: Current condition
list, transient condition list, retired condition list.

Randy: I believe that Sharon has a slide which will detail what An-Ni
just described (slice/dice).

A more detailed example is a case where you suppress a particular
notification if something is being provisioned.

Audience: What is an alarm profile?

An-Ni: For some cases alarm is critical, some minor.

Randy: For example, administrator has declared that I care about
LOS on T1 but not dialup.

Randy: We've got suppression, degradation, filtering. I think that
if it sounds like we want to look at this side of the problem, this
would be a good question for the mailing list. First we want to look
at slice/dice.

Randy: Next presentation from Kam Lam.

Kam: ARC MIB. Needs for suppression of alarm reporting. Needs for
automatic in service provisioning.

Randy: Is it fair to say that currently in several MIBs we have
mechanisms for turning off notification of a particular type. This
provides a generic mechanism for new MIBs.

Andy Berman: Delaying is a lot different that suppression.

Randy: If it is cleared, you don't want it to go into the log.

Kam: Once an entry transitions from ARC mode to ALM state, the entry
will disappear from table.

Audience: How is this related with X.734?

Randy: Closest to EFD is described in RFC 2574 where notification MIB
provides a capability crudely equivalent to EFD.

Audience: EFD is shut at destination, whereas you are trying to shut
it off at the source.  This is an important point.

Sharon: Alarm MIB requirements. Conditions MIB is solving a different
problem than active alarm tables. Persistent versus non-persistent
indication of alarms.

Randy: Only SOME conditions are treated as alarms.

Sharon: Initial slice: Separate MIBs for alarm definition and active
alarm management.  Conditions and ARC.

Randy: I'd like to get a sense who believes we should continue working
on the capability Active Alarm Table? Many raised hands. One objection:
this is getting too complex, my requirements satisfied by notifications
log mib.

Dave Perkins: Not all notifications are alarms. Does the objector
understand this?

Randy: The second chunk of work: defines condition detection. Is
there any support? A few show of hands. Vehement opposition from same
objector. To him this is too much burdensome.

Audience: Be careful in gauging broad consensus. Most people are in
the middle between vehement opposition and support, but have no great
suggestion. No response =/= assent.

Randy: ARC. Selectively throttle. What is consensus? A few show of
hands. Strong opposition. None. Extrapolating that, I believe this
means we have at least one additional document that would have within
it the ARC, and the condition mib. Is that acceptable as a straw man.
Already, there are editors. Others welcome to contribute. Area director
Bert said it is fine with him. Anything else on slice and dice?

Audience: Condition, alarm, ARC are closely related, so definition of
documents should be coordinated. Moderators agreed.

Audience: If you are finishing with this framework, specify in the
documents what relationship with other documents.

Randy. We will meet again on Tuesday.

Minutes of 3/21 Distributed Management Working Group

Randy Preshun started the meeting by proposing and receiving acceptanced
of an agenda for this meeting:

I.  Working Group Discussion: What if anything needs to be done
in terms of additions/corrections to notification log mib based on
what is coming in from event/scheduling mib experience?

II.  What we need to do with other scripting related discussions?
   -- Andy Bierman, SEE
   -- Juergen Schoenwalter, SMX

An unofficial third point emerged, in the discussion of a few points of
working group administrivia.

I.  Notification Log MIB:
-------------------------

(Some of the more notable commentary follows)

Sharon and Randy: If deployment has uncovered inefficiencies or
perceived inefficiencies, it is in the interest of the working group
not to create a new MIB but fix those inefficiencies.

David Perkins: believes MIB in its current form is not
"understandable". Randy noted: at least one object in MIB which is
redundant, others may be "suboptimal".

Ram Kavasseri: (document editor) notes, Others have working
implementation, and asks, What specifically is not workable? Need
customers who are deploying it to give feedback. Randy notes, such
feedback MUST go to the working group list.

David gave some initial impressions about "nonworkability": The
MIB does two things depending on where it's deployed, which is a
confusing and not efficient practice.  Second: If SNMP traps used,
they can be dropped en route to manager.  Hence, Information can be
duplicated in log.

Some points of discussion on these claims followed.

ACTION ITEM: Randy asks that David post his issues with the logging
to the working group mailing list (along with other performance
issues etc.).  Would like to see this happen "sooner rather than
later".

II. Disman-related scripting work
---------------------------------

Andy Bierman: presented the points of relevance and context of his
current individual submission: draft-bierman-disman-see-00.txt, the
*Script Execution Environment (SEE) Specification*.

The submission itself is fairly lengthy and the details of SEE I-D
content were stipulated as out of scope for the purposes of this
discussion.

The original Script MIB tried to hide device and mechanism complexity,
reduce exposure to single points of failure, and reduce incident
response latency.

To the extent of addressing these needs in the disman environment,
this first solution was on right track, but critical system components
are missing:

-- a standard prog. language
-- a standard runtime environment in which to execute scripts.

Need to:
-- choose a language (Andy notes that any suitable language will do,
although Andy has SEE language, and thinks it should be evaluated for
fitting the bill)
-- the capabilities of the somewhat should reflect a runtime environment

The language: should include special features for SNMP: OID
assembly/manipulation, string encodings for necessary data types.

The runtime environment needs a framework:

  -- a mechanism for establishing and passing named script parameters
  -- a clear notion and expression of per task runtime permissions
  -- attribute centric access control for each library function,
  -- documentation templates for scripts and libraries.
  -- a notion of standard and vendor system libraries.
  -- a notion of task groups
  -- capability for scoped "Environment variables" accessible to the
     script runtime.
  -- DIAGNOSTIC facilities, very essential.

The essential design tradeoff is between a Script engine versus a
Full operating system:

        -- Full arithmetic logic?
        -- Conditionals?
        -- Iteration?
        -- Functions?
    -- Run to completion scheduling?

It is likely that the above functions are essential, but a complete
operating system is not needed for net management shell.

An Initial profile communicates the execution requirements of a script.
SEE provides a few top level profile options:

  -- An "unconstrained" script is invoked when value of any instance
     of a specified MIB object changes value.
  -- Periodic profile: invoked once per time interval
  -- Calendar profile: unconstrained script invoked via Scheduling MIB.
  -- Notification filter profile: Partially constrained script
     is invoked just before a notification is issued.

Relationship to Policy Management MIB Module from SNMPCONF working
group (aka "PM MIB"): Andy sees these as Similar solutions to
different problems.  SEE is centered on Applications unrelated to
policy-based configuration (his classic example: rotate-logs.sh).
PM is s specialized application for policy based configuration
of device elements.  Andy also believes that PM lends itself to
an expectation that NMS application will write PM MIB-managed
scripts, whereas the SEE scripting is more suitable for human
originated/edited scripts.

So, overall, PM is not and should not be a general purpose scripting
environment--that's what the script MIB is for as it pertains to
the scripting environment specifically.  Within that environment, PM
scripts are really callback functions, triggered upon the activation
of their filters.

To refine the Script MIB usage from this view, the Script MIB
accomplishes the aims of:

  -- language registry
  -- language extension registry
  -- script transfer mechanisms
  -- script storage
  -- Integration with scheduling MIB.

PM language could be a subset of SEE language.  The proper SEE
integration would leave function calls, floating point, etc. out of PM.
Similarly OID expressions and OID aliases are covered by SEE.

Looking at it from the point of view of PM integration,
  -- The Runtime Environment covers: debugging and logging.

  -- SEE covers application profiles, names parameters and environment
     variables, explicit runtime permissions.

  -- PM could use: roles, etc.

Notable Questions:

Steve Waldbusser--what is the placement of application profiles
in the environment?  Andy: essentially, documentation, predefined
environment variables.

Several: Issue of coupling/dependencies between runtime environment
architecture and language architecture.  In particular, is there
any inherent dependency by the runtime environment on the language?
Could this adapt to demands for handling interpreters for legacy
scripting languages? (Perl and Python mentioned) Andy:the specification
has made the language and runtime environment set up to be independent
and replaceable with respect to the other (up to a point).

Resolution/ACTION ITEM: continue discussing this on mailing list,
and if "critical mass" emerges to pursue this, then Randy talks to
Bert and sees about extending charter to include some work here.
Furthermore, a caucus of present Working Group members with
interest in scripting environments will meet and report on any
consensus/discoveries.

SMX/Juergen Schoenwalter
-------------------------

Juergen spoke briefly about the work he's been doing privately
on SMX and his belief that it coincided a bit with work going on
within the working group. SMX represents a runtime system boundary
for the Script MIB, and is already published as experimental in
RFC 2593.  Juergen mentioned the availability of a second version
of SMX as an individual submission Internet draft, and felt it was
paralleling discussion of these topics within disman.  He wanted
to briefly ask anybody who had encountered the draft as to whether
the Disman working group wanted to take this on within the charter.
As there were no takers on the working group floor, no action was taken.

Other Administrivia
-------------------

ACTION ITEM: Script MIB to be handed off to Bert to take to IESG, no
final comments.

changes to target dates: still tracking script work dates as current.

To summarize anything threatening to turn into an additions to charter:
still need to discuss Andy's work on SEE. Proposal on means of talking
amongst mid-level managers.

Who is editing team for alarm report condition stuff, report to
mailing list?

Gideon Stupp of Sheer Networks wanted to indicate their development
of interface architecture for distributed provisioning management
and asked if there was any group interest in it.  Randy indicated
that publishing details on this technology to the working group list
would be the best way to pursue this.

ACTION ITEM: Andy Bierman will write up what's wrong with the Script
MIB in its current draft form.

ACTION ITEM: Dave Perkins to provide comments and concerns on
notification log MIB.