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

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

(Margaret Cullen; former steering group member) Yes

Yes (2004-01-08 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
This document is exceptionally clear and well-written.

(Alex Zinin; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Allison Mankin; former steering group member) No Objection

No Objection (2004-01-07 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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 steering group member) (was Discuss, Yes) No Objection

No Objection ()
No email
send info

(Bill Fenner; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Harald Alvestrand; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Jon Peterson; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Ned Freed; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Steven Bellovin; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Ted Hardie; former steering group member) No Objection

No Objection (2004-01-06 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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 steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info