Subject: [ipcdn] draft-ietf-ipcdn-docsisevent-mib-00.txt

From: Michael MacFaden <[email-masked]>
Date: Wed, 22 Nov 2000 12:27:04 -0800

Hi,

A good start on a trap mib for cable modems.
Here are some things to consider in the next version.

When defining traps using SMIv2, please be sure to follow the RFC 2576
section 2.1.2 so that it will be possible to have a DOCSIS 1.0 device
implement the NOTIFICATIONS using SNMPv1 traps or for a Proxy
to convert from SNMPv1 traps to SNMPv2c/V3 NOTIFICATIONS.

Also, I'd like to introduce you to the work going on in
SNMPCONF working group regarding designing traps.

This working group is defining a Best Current Practice for
Configuring Networks and Devices with SNMP. Here
was the slide presentation at Pittsburg:

http://www.ietf.org/proceedings/00jul/SLIDES/snmpconf-bcp-status/index.html

The working group documents are here:
http://www.ietf.org/html.charters/snmpconf-charter.html

In particular, I hope the mib will consider these BCP's for trap mib design:

1) Since any traps sent are unreliable if sent in SNMPv1, be sure that
there are underlying objects that can be polled.

2) Design in an upper limit to the number of traps of that may be sent.
Otherwise, an object such as RFC 2115's frTrapMaxRate may be useful
so that mgmt stations are not overwhelmed by thousands of cable modems.

3) Design traps so they can't be used in DoS attacks. The authTrap from
RFC 1215 sends one trap for every bad snmp msg it gets. It is an example
of how not to define an snmp trap and would be even worse if it was
a notification that required acks from the mgmt station.

If there were any other items you found useful in design, the snmpconf
working group would be interested in them.

Regards,
Mike MacFaden
Riverstone Networks, Inc
www.riverstonenet.com

_______________________________________________
IPCDN mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/ipcdn