Alarm Reporting Control Management Information Base (MIB)
Note: This ballot was opened for revision 10 and is now closed.
(Bert Wijnen) Yes
(Harald Alvestrand) No Objection
(Steven Bellovin) No Objection
(Randy Bush) No Objection
(Margaret Cullen) (was Discuss) No Objection
(Bill Fenner) No Objection
(Ned Freed) No Objection
(Ted Hardie) No Objection
The ToC needs to have numbers added. Buried in the ARCState description is: " Note that the state alm (alarm reporting is allowed) is not listed in the enumeration of the value of this object. However, this state is implicitly supported by the mib. Once a resource enters the normal reporting mode (i.e., in the alm state) for the specified alarm type, the corresponding row will be automatically deleted from the arc table. Also the manual setting of arcState to alm can be achieved through setting the RowStatus object to 'destroy'. This seems a major enough design decision on how to accomplish the work to move it into the text of the document or repeat it there. The second "even then" in the following text from the Security Considerations seems spurious Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module.
(Russ Housley) No Objection
The ability to remotely shut off alarms seems to have a slightly different security consideration that the usual MIB document, yet this document has the typical boilerplate. I do not feel strong enough to register a DISCUSS, but there is something unsettling. Part of the reason that I do not want to register a DISCUSS is because the alarms themselves are not described in this document. The context of the alarms needs to be understood to determine the security consequences of masking them.