Alarm Management Information Base (MIB)
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' **)
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' **)
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' **)
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?