and have the following comments:
1. (Overview) In general, while current NMS and Printer MIB solutions =
seem
to be performing adequately, I agree with the underlying premise of SEN=
SE,
that there is room for widespread application of event driven network d=
evice
management and view this as an evolutionary step.
2. (Overview) Simple is stressed as an overriding characteristic of th=
e
requirements. I wonder if the current model, with it's publication and =
edition
paradigm is really as simple as originally intended. This would be unfa=
ir as a
criticism (and is not intended as such) since I do not have an alternat=
ive
model to offer. It's just an observation that the current state of the
architecture may not fit the icon of simplicity put forth in the requir=
ements.
Simple is a very hard thing to define and it may be better to avoid the=
term.
Given that events really capture the essence of the situation perhaps t=
he name
should be changed to ES&NSE (Event Subscription & Notification Services=
Environment).
3. (SENSE Requirements) The primary motive... lack of good Trap regist=
ration
and distribution in SNMP may well be handled in SNMPv3. This motivation=
should
be re-investigated.
4. (#14) Client ACK of event. I'm not sure this should be required in =
all
cases. Perhaps 2 modes, an ACK or NotACK mode. This will help alleviate=
(#16) -
server resource management. The server can really bloat while waiting f=
or ACKs
from clients who disappear etc. It is feasible to consider an "unreliab=
le" mode
of operation.
5. (not addressed) The requirements do not appear to directly address =
the need
for filtering. I know the requirements do not address data content and =
it could
be argued this is where this topic belongs, but I think filters are sig=
nificant
to any event based scheme and should at least be mentioned. I also ackn=
owledge
that filtering is exactly one of the reasons the current SENSE architec=
ture may
appear somewhat less than simple (my comment 2, above).
Harry Lewis - IBM Printing Systems
=