Check MIB module

Dear all,

Happy new year!

At NEC we tried to use a combination of the Event MIB and the
Expression MIB for remote health check operations on a large set
of small managed devices.  We found the overhead of development
cost, footprint and complexity of usage rather high for this
application.

Many nice features were hardly used, while a few were sufficient
to fulfill most of our requirements.  For most of our health checks
we were fine with
  - a compare operation between an arbitrary managed object and
    a constant value
  - a logical AND operation over the results of all comparisons

In the end we wrote a new MIB module, the Check MIB
<http://www.ietf.org/internet-drafts/draft-nunzi-check-mib-00.txt>,
with a hard coded AND operation and configurable compare operations.
We added a few more features, such as a severity for each comparison,
a notification mechanism, a list of failed comparisons and some means
for dealing with situations were resources at small managed nodes are
very limited.  In the end the Check MIB turned out to be smaller and
simpler than the individual Event MIB or the individual Expression
MIB.  Certainly, this is due to the fact that we concentrate on
remote health check operations.

We want to further develop and improve the Check MIB.
Everybody who wants to join us is very welcome!

I-D ACTION:draft-ietf-disman-alarm-mib-17.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.  This draft is a work item of the Distributed Management
Working Group of the IETF.

	Title		: Alarm MIB
	Author(s)	: S. Chisholm, D. Romascanu
	Filename	: draft-ietf-disman-alarm-mib-17.txt
	Pages		: 70
	Date		: 2004-1-6
	
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes management objects used for defining
and storing alarms.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-17.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-disman-alarm-mib-17.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Fw: disman-alarm MIB

Hi -

I'm forwarding part of an off-list discussion with the AD and editors of the
Alarm MIB.  The problem is that the registry procedures need to be clarified.
Any constructive proposal would be appreciated.  Follwing the extract of
the discussion is my attempt at a clarification.

> > > Another issue that came up today (From IANA) is that it
> > > is not clear to them how they assign new values:
> > >
> > >    IANAItuProbableCause ::= TEXTUAL-CONVENTION
> > >        STATUS current
> > >        DESCRIPTION
> > >            "ITU probable cause values. Duplicate values defined in X.733
> > >            are appended with X733 to ensure uniqueness. Probable cause
> > >            value 0 is reserved for special purposes.
> > >
> > >            The Internet Assigned Number Authority (IANA) is responsible
> > >            for the assignment of all Internet numbers, including
> > >            various SNMP-related numbers, and specifically, new
> > >            IANAItuProbableCause values. Values of
> > >            IANAItuProbableCause less than 1024 are reserved for causes
> > >            that correspond to ITU probable cause. IANAItuProbableCause
> > >            of 0 is reserved for special purposes and therefore cannot
> > >            be assigned. See http://www.iana.org"
> > >
> > > To me it sounds that ITU defines new values, and then when they ask
> > > IANA, then IANA will add them. Is that how we envision this?
> > > Should we mention ITU-SG 4 as the one to ask for such values?
> >

Re: Fw: disman-alarm MIB

Re: Fw: disman-alarm MIB

Hi -

> From: "Robert Moore" <remoore <at> us.ibm.com>
> To: "Randy Presuhn" <randy_presuhn <at> mindspring.com>
> Cc: "Disman (E-mail)" <disman <at> ietf.org>; <disman-admin <at> ietf.org>
> Sent: Friday, January 09, 2004 5:26 AM
> Subject: Re: [Disman] Fw: disman-alarm MIB
...
> Obviously, I haven't been following these discussions closely.  But to
> make sure everybody's on the same page, the text should say clearly which
> of the following types of requests IANA is supposed to honor for the FCFS
> range:
>
> (a) "I need *a* probable cause code point for METEOR STRIKE."

Of course.

> (b) "I need you to assign code point x2000 to the probable cause METEOR
> STRIKE."

I do not believe this was intended.  The only reason for
reserving a particular range of values for the ITU was
convenience.

> When you say "All other requests for values ...," it's not clear whether
> requesting a value means (a), (b), or both.
...

What I meant in my proposed clarification was that any request for
a value, which did not correspond to an ITU-assigned value less
than 1024, would be given an FCFS assignment, starting with 1024
and working up.  So, if ITU goes beyond 1023, the TC value and
the corresponding ITU value will likely be different.

Clear as mud?

Randy

Alarm management standards & practices

Fwd: [RMONMIB] - statistical sampling for columnar objects

submitting -00- disman drafts?

Hi -

If you're planning to submit -00- internet drafts, and it
would be appropriate for them to bear the draft-ietf-disman-
string in their names, and you would like to avoid delays in their
processing, please let me know by Friday of this week so I
can inform the secretariat.  My internet access from January
17 to February 2 will be rather limited, if there is any at all.

Likewise, non-subscriber posts to the WG mailing list may be
delayed during that time.

Randy
disman WG chair

Issues from IESG Alarm MIB Review

Hi

I will propose resolutions to these in separate emails.

IESG-1 

"Another issue that came up today (From IANA) is that it
is not clear to them how they assign new values:

   IANAItuProbableCause ::= TEXTUAL-CONVENTION
       STATUS current
       DESCRIPTION
           "ITU probable cause values. Duplicate values defined in X.733
           are appended with X733 to ensure uniqueness. Probable cause
           value 0 is reserved for special purposes.

           The Internet Assigned Number Authority (IANA) is responsible
           for the assignment of all Internet numbers, including
           various SNMP-related numbers, and specifically, new
           IANAItuProbableCause values. Values of
           IANAItuProbableCause less than 1024 are reserved for causes
           that correspond to ITU probable cause. IANAItuProbableCause
           of 0 is reserved for special purposes and therefore cannot
           be assigned. See http://www.iana.org"

To me it sounds that ITU defines new values, and then when they ask IANA,
then IANA will add them. Is that how we envision this? Should we mention
ITU-SG 4 as the one to ask for such values?

Can we add some text w.r.t. the FCFS assignments as to why we do not worry
about possible overlap and that this is OK? In otehr words, are we sure
nobody can screw us up one way or another. We have had some bad expericence
with large FCFS spaces in the recent past. That is why  it comes up."

IESG-2

"In the Terminology section, the draft says:

  Alarm Clear
    The detection that the fault indicated by an alarm no longer
    exists.  A Notification SHOULD be sent on alarm clear.

I'm a bit concerned about imposing a  requirement like this in the
terminology section.  Is a better place to impose this available?"

IESG-3

"In Section 3.4, the draft says:

  Security for alarms is awkward since access control for the objects
  in the underlying Notifications can be checked only where the
  Notification is created.  Thus such checking is possible only for
  locally generated Notifications, and even then only when security
  credentials are available.

This is very hard to parse, since it is difficult to understand whether the
kind of security we're talking about is access control for the alarms
themselves, access control to which Notifications refer, or something.  It
would help me, I think, if it said "for this $THREAT, there are the
following issues"."

IESG-4

"typo in the IANA Considerations --

"Values of IANAProbableCause greater than 1024" should be
IANAItuProbableCause""

IESG-5

"As far as allowing the ones over 1024 to be assigned FCFS, is this a good
idea?  What if ITU assigns them in a future document?"

In addition, there was an issue found that in the ITU Alarm MIB counter32 is
defined but not used. I will call that Other-1

Sharon Chisholm
Portfolio Integration
Nortel Networks
Ottawa, Canada

Proposed Resolutions to iesg-2, iesg-3, iesg-4 and other-1

Hi

-------------------
The following is the proposed resolution to iesg-2

Replace

"  Alarm Clear
    The detection that the fault indicated by an alarm no longer
    exists.  A Notification SHOULD be sent on alarm clear."

With

"  Alarm Clear
    The detection that the fault indicated by an alarm no longer
    exists.  "

And add the following text at the end of the first paragraph in 3.3.2. 

"  Alarms SHOULD be modelled so Notification are sent on alarm clear."

-------------------
The following is the proposed resolution to iesg-3.

In section 3.4 replace

" Security for alarms is awkward since access control for the objects
  in the underlying Notifications can be checked only where the
  Notification is created.  Thus such checking is possible only for
  locally generated Notifications, and even then only when security
  credentials are available."

" Given the nature of VACM, security for alarms is awkward since 
  access control for the objects in the underlying Notifications 
  can be checked only where the Notification is created.  Thus 
  such checking is possible only for locally generated Notifications, 
  and even then only when security credentials are available."

-------------------
The following is the proposed resolution to iesg-4. 

Replace 

"assigned. Values of IANAProbableCause greater than 1024 may be"

With

"assigned. Values of IANAItuProbableCause greater than 1024 may be"

--------------------
The following is the proposed resolution to other-1

Remove couter32 from the imports in the ITU-ALARM-MIB

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

Sharon Chisholm
Portfolio Integration
Nortel Networks
Ottawa, Canada