Skip to main content

Alarm Management Information Base (MIB)
draft-ietf-disman-alarm-mib-18

Yes


No Objection

(Alex Zinin)
(Bert Wijnen)
(Bill Fenner)
(Harald Alvestrand)
(Jon Peterson)
(Ned Freed)
(Russ Housley)
(Steven Bellovin)
(Thomas Narten)

Note: This ballot was opened for revision 18 and is now closed.

Margaret Cullen Former IESG member
Yes
Yes (2004-01-08) Unknown
This document is exceptionally clear and well-written.
Alex Zinin Former IESG member
No Objection
No Objection () Unknown

                            
Allison Mankin Former IESG member
No Objection
No Objection (2004-01-07) Unknown
Typo in the IANA Considerations --

"Values of IANAProbableCause greater than 1024" should be IANAItuProbableCause

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?
Bert Wijnen Former IESG member
(was Discuss, Yes) No Objection
No Objection () Unknown

                            
Bill Fenner Former IESG member
No Objection
No Objection () Unknown

                            
Harald Alvestrand Former IESG member
No Objection
No Objection () Unknown

                            
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Ned Freed Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Steven Bellovin Former IESG member
No Objection
No Objection () Unknown

                            
Ted Hardie Former IESG member
No Objection
No Objection (2004-01-06) Unknown
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?

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".
Thomas Narten Former IESG member
No Objection
No Objection () Unknown