Subject: draft 51stIETF DISMAN WG Minutes

From: Lauren Heintz <[email-masked]>
Date: Fri, 10 Aug 2001 12:15:16 -0700

Hi,

Here is the first cut at the DISMAN minutes.
Please send any corrections/omissions/etc.

In the next few days I may consolidate
another set of notes I am shortly expecting
into this set (or vice versa).

Thanks, Lauren

--------------------------------------------------------

51st IETF (London) DISMAN WG, 06/08/2001, 0900 GMT

Meeting chaired by Randy Presuhn

Minutes compiled by Lauren Heintz

Note: Search for "***" for action items.

Randy opened with agenda bashing.  David Perkins
requested to add a review of the notification
log MIB to the agenda, and this was accepted.

Randy gave status updates for various MIBs:
the script MIB is now in IETF last call;
the schedule MIB is in the hands of IESG;
there may be an inconsistency between
the expression and event MIBs; the remote OPs,
event and notification-log MIBs are proposed
stds; the noitification-log MIB apparently has one
object that needs deprecation.

The latest Alarm MIB draft is now at v02,
and incorporates the ITU-Alarm MIB.

The Condition MIB, v01, is now being written
and is slated to replace older condition,
Alarm and ARC MIBs.  An issue was raised that
only published drafts should be discussed,
but the group decided to allow discussion of the
forthcoming Condition MIB.

David Perkins suggested that the Alarm MIB may
not have fully considered Telcordia requirements
and asks that Telcordia Alarm models and terminology
be considered/adopted.  Kam suggested ITU is a superset
of Telcordia.

Bert asked David to research Telcordia documents
and perhaps coordinate a "loan" of such to the IETF
DISMAN WG.  ***David agreed to take an action item
on this.

Sharon presented the ITU Active Alarm MIB:
overview, changes since Minneapolis, Issues.

The v02 draft now includes these changes:
- architecture goals section
- alignment with condition and ARC
- added optional generic alarm notifications
- made alarm state transitions to be more flexible
- combined drafts. though MIBs remain in separate MODULEs
- added more examples
- created ITU IANA TC

Active alarm MIB is independant of condition MIB;
may need more work to decouple them more

May want IANA to control certain TCs (e.g. probable cause).
As a rule of thumb, it was stated that IANA should control
TCs that change over time.

It was stated there was no need to create a new ID
for TCs not destined for IANA.  Instead,
they should be put in the Active Alarm MIB document.
This caused some debate: Dan Rom' cautioned about linking
IDs and the need to avoid cyclical dependencies, Sharon
wanted stand-alone TC MIB within the Alarm ID, Mike Ayers
does not want too many IDs.  It was decided that consolidation
was a good short term strategery and that things could change
a bit later on if the situation warranted it.

David (?) - Alarm Model State in example 6 incorrectly
uses ITU Severity states, which are unordered.

David Perkins raised new issues about terminology,
incorrect usage of SHOULD/MUST/etc.  ***David
should send these detailed issues to the list.
*** Randy promised/volunteered that the editors would
track all raised issues.

*** Randy took an action item to update
the charter with the revised/consolidated
MIB lists.

David Perkins raised concern whether the
ActiveAlarmTable could be used by a manager.
He is mainly concerned about the use of TimeFilter,
which he contends is incorrectly used in this case.
Dan Rom' indicated TimeFilter was added as an index
to help managers efficiently determine whether a specific
Alarm had been cleared or not.  This is because another
mechanism does not exist in the MIB to determine what
alarms had been cleared since a prior manager/agent
alarm sync.  No objections were heard to a proposed
requirement to have an efficient mechanism to determine
cleared alarms.

A debate ensued about whether or not alarms need to be
reportable without notifications.  Randy indicated that
for implementations that chose to use the AgentX notify
PDU, notifications would result.

A question was raised about whether the current
mechanism for matching notifications to conditions
is sufficient.  ***Sharon took an action item
to provide audit results to the list for further
discussion.

Kam discussed the new, as of yet unpublished, condition
MIB.

It was pointed out that TimeInterval has potential issues
in distributed architectures if provided as a scalar
instead of within a table.

Sharon raised an issue about inconsistent indexing in the
v00 draft MIB version and suggested ARC and alarm MIBs
should use consistent indices that are also conducive
to the entity MIB.

Mike raised concerns about whether it is proper to
tie alarms and entities together, and Dale suggested
that entPhysicalIndex is very appropriate to use.
*** Mike took an action item to raise a thread on
the list about the mechanism to identify alarm
sources and whether the entity MIB is useful.
It was suggested we need to refrain from
defining custom alarm source defs and to
perhaps instead use OIDs to allow generic source IDs.

*** Kam took an action item to bring discussion
to list regarding notification-log MIB
security issues.

The group was asked whether there were
suggestions for further script MIB work
within DISMAN WG?  No respone.

Charter updates were considered and it was
decided that the March 01 date for recycling
the log-mib needed more thought.  It was also
suggested that the August01 milestone (alarm MIB)
needed a new date.

Dan Rom' suggested a last-call was possible for the
Alarm mgmt MIB for a late December or early January.
*** Randy took an action item to get Bert suitably
sauced to get this accepted.

It was stated that the current December charter
milestones were still feasible as of now.
NOTE: I see no December milestone on the charter
(which was last updated 9 August -- today).  Perhaps
we were instead talking about the "proposed" December
milestones above?

*** Mike took an action item to discuss
arch' issues about justification for
differences between alarm and condition
MIBs.

*** Kam and Sharon took an action item to ensure
docs are clearer about the distinction and
also the complimentary nature of alarm and condition
MIB.

EOF

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 13 Aug 2001 10:08:13 +0200

Two notes on the draft minutes.

[...]

Lauren> Randy gave status updates for various MIBs: the script MIB is
Lauren> now in IETF last call; the schedule MIB is in the hands of
Lauren> IESG; there may be an inconsistency between the expression and
Lauren> event MIBs; the remote OPs, event and notification-log MIBs
Lauren> are proposed stds; the noitification-log MIB apparently has
Lauren> one object that needs deprecation.

I was not in the room when Randy gave the status update - so I do not
know whether Randy or the minutes are incorrect here. Anyway, here is
what the status of the script and scheduling MIBs really is:

- script MIB is in the hand of the RFC editor
- schedule MIB is in IETF last call (until August 28)

[...]

Lauren> David Perkins raised concern whether the ActiveAlarmTable
Lauren> could be used by a manager.  He is mainly concerned about the
Lauren> use of TimeFilter, which he contends is incorrectly used in
Lauren> this case.  Dan Rom' indicated TimeFilter was added as an
Lauren> index to help managers efficiently determine whether a
Lauren> specific Alarm had been cleared or not.  This is because
Lauren> another mechanism does not exist in the MIB to determine what
Lauren> alarms had been cleared since a prior manager/agent alarm
Lauren> sync.  No objections were heard to a proposed requirement to
Lauren> have an efficient mechanism to determine cleared alarms.

I think it is worthwhile to add a note here that TimeFilters do not
help to address the requirement. TimeFilters can help to identify the
rows that changed since the last poll - they do not help to identify
the rows that got added/deleted since the last poll.

/js

---

From: Lauren Heintz <[email-masked]>
Date: Mon, 13 Aug 2001 09:39:49 -0700

Hi,

I'm sure I am the culprit regarding the
incorrect status.  I remember thinking
at the time "I hope I got this right",
and I guess I didn't.

Thanks,
Lauren

---

From: a huynh <[email-masked]>
Date: Mon, 13 Aug 2001 10:51:06 -0700 (PDT)

Hi.  Missing the London meeting discussion,
Lauren's minutes is a great help.  Thanks.
See comments in line.

Anni
----------------------------------------------------
> should use consistent indices that are also
[Anni]  I don't think the ARC MIB should be indexed
the same way as the condition MIB, unless we want to
restructure the conditon (or alarm) tables to list
the conditions(or alarms)by managed resource.

The ARC table is to control what condition and 
when to sent an alarm per managed resource (see
the usage of ARC MIB),
while the condition (and alarm) MIB is a list of
conditons(or alarms.  

> sources and whether the entity MIB is useful.

[Anni]
entPhysicalIndex were seriously considered and is not
used because:
*  it does not covered all managed resources that are
not physical entities,
*  many devices do not support the entity MIB.

> perhaps instead use OIDs to allow generic source
[Anni] Yes.
> differences between alarm and condition
[Anni] If we consider that an alarm is an indication
of a abnormal condition of a managed resource, then
I don't think there are big difference between alarm
and conditions.  Following this definition,
the active alarm table (Sharon & Dan's) would be an
a subet (some condition does not generate alarm) and
an abstraction (in their application, detail
information are listed in another table).

The architecture shown in the Condition MIB is a 
starting points, of course it needs more works, :-).
Mike and Disman members, I would like to get 
your views.

__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

---

From: a huynh <[email-masked]>
Date: Mon, 13 Aug 2001 11:06:40 -0700 (PDT)

Hi, Kam & Sharon.
--------
Action item from London meeting:
*** Kam and Sharon took an action item to ensure
docs are clearer about the distinction and
also the complimentary nature of alarm and condition
MIB.
--------
  
We do indeed need more discussions on these two
documents.

Before the London meeting, Kam and I are talking about
some short interim conference.

Will either you provide a bridge for the design team?

Regards,
Anni

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 14 Aug 2001 09:10:18 +0200

>>>>> a huynh writes:

Anni> [Anni] entPhysicalIndex were seriously considered and is not
Anni> used because: * it does not covered all managed resources that
Anni> are not physical entities, * many devices do not support the
Anni> entity MIB.

Can you give examples of managed resources that are sources of alarms
and which are not covered by the entity MIB?

Your second argument is IMHO not very convincing since no device at
this point implements the alarm MIB either. I expect that the entity
MIB will be one of the core IETF MIB modules in the future - much like
the IF-MIB. So having a well defined pointer back to the entity MIB
seems valuable to me.

/js

---

From: a huynh <[email-masked]>
Date: Tue, 14 Aug 2001 10:04:40 -0700 (PDT)

HI.
--- Juergen Schoenwaelder <[email-masked]>
> and which are not covered by the entity MIB?

I think entPhysicalIndex is useful but not sufficient
to identify resource that is not a physical entity.
One example is the optical interface sub-layer.
It is identified by ifIndex not entPhysicalIndex.
Using OID as alarm source is more desirable.

I have raised this point before in the mailing list,
and would like to have a consentment that this is a
good approach.  This is one of critical item for the
condition mib and arc mib.

> the IF-MIB. So having a well defined pointer back to

I would be nice that entity MIB as well supported
as IF-MIB. see previous comments.

Anni

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 15 Aug 2001 10:15:59 +0200

>>>>> =?ISO-8859-1?Q?=C1=D6=CF=FE=C1=D2?=  writes:

Alex> Hi,my friend,could you send me some information about storage
Alex> MIB?  Best Regard Alex Lan [email-masked]

Do you mean <draft-schoenw-storage-type-00.txt>? This document is
currently being revised and a new revision should show up relatively
soon.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 Aug 2001 12:10:01 +0200

>>>>> a huynh writes:

Anni> I think entPhysicalIndex is useful but not sufficient to
Anni> identify resource that is not a physical entity.  One example is
Anni> the optical interface sub-layer.  It is identified by ifIndex
Anni> not entPhysicalIndex.  Using OID as alarm source is more
Anni> desirable.

Anni> I have raised this point before in the mailing list, and would
Anni> like to have a consentment that this is a good approach.  This
Anni> is one of critical item for the condition mib and arc mib.

I think a RowPointer is fine as long as we have clear text in the
DESCRIPTION which explain which OIDs to use in certain common cases so
that management applications have a better chance to do useful stuff
with the OID value:

     If the source of the alarm is a logical interface, then the value
     of the RowPointer must be the OID of the corresponding ifIndex
     object. If the source of the alarm is a physical entity, then the
     value of the RowPointer must be the OID of the corresponding
     entPhysicalDescr object.

There might be other common things - perhaps we need also pointers 
into the HOST-RESOURCES-MIB for processes and such things.

/js