Alarm Management Information Base (MIB)
RFC 3877

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

(Margaret Cullen) Yes

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

(Harald Alvestrand) No Objection

(Steven Bellovin) No Objection

(Bill Fenner) No Objection

(Ned Freed) No Objection

(Ted Hardie) No Objection

Comment (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".

(Russ Housley) No Objection

(Allison Mankin) No Objection

Comment (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?

(Thomas Narten) No Objection

(Jon Peterson) No Objection

(Bert Wijnen) (was Discuss, Yes) No Objection

(Alex Zinin) No Objection