[dhcwg] Re: draft-bakke-dhc-snmp-trap-00.txt

Mark Bakke <mbakke@cisco.com> Mon, 16 September 2002 19:28 UTC

Received: from www1.ietf.org (ietf.org [] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15068 for <dhcwg-archive@odin.ietf.org>; Mon, 16 Sep 2002 15:28:26 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8GJTkk18984 for dhcwg-archive@odin.ietf.org; Mon, 16 Sep 2002 15:29:46 -0400
Received: from ietf.org (odin.ietf.org []) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GJTkv18981 for <dhcwg-web-archive@optimus.ietf.org>; Mon, 16 Sep 2002 15:29:46 -0400
Received: from www1.ietf.org (ietf.org [] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15030 for <dhcwg-web-archive@ietf.org>; Mon, 16 Sep 2002 15:27:56 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain []) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GJ79v17988; Mon, 16 Sep 2002 15:07:09 -0400
Received: from ietf.org (odin.ietf.org []) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GJ3rv17612 for <dhcwg@optimus.ietf.org>; Mon, 16 Sep 2002 15:03:53 -0400
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14378 for <dhcwg@ietf.org>; Mon, 16 Sep 2002 15:02:03 -0400 (EDT)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com []) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8GJ3IKB008588; Mon, 16 Sep 2002 12:03:18 -0700 (PDT)
Received: from nisser.cisco.com (localhost []) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8GJ3Hwt024281; Mon, 16 Sep 2002 12:03:17 -0700 (PDT)
Received: from cisco.com (mbakke-lnx.cisco.com []) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA25980; Mon, 16 Sep 2002 12:03:15 -0700 (PDT)
Message-ID: <3D862F76.CAA63701@cisco.com>
Date: Mon, 16 Sep 2002 14:22:30 -0500
From: Mark Bakke <mbakke@cisco.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: "'dhcwg@ietf.org'" <dhcwg@ietf.org>, "snmpv3@lists. tislabs. com (E-mail)" <snmpv3@lists.tislabs.com>, mibs@ops.ietf.org
References: <6D745637A7E0F94DA070743C55CDA9BA0757E3@NHROCMBX1.ets.enterasys.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [dhcwg] Re: draft-bakke-dhc-snmp-trap-00.txt
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Here's another try at the snmp notification option for DHCP.  It's
not a formal draft; just a rough idea of what it might look like.
If this seems to be the right approach, I'll issue another revision
of the draft.

I also changed this from a binary structure to a text format, since it
needed to be fairly flexible.


DHCP snmp-trap-host option

Here's a quick sketch of what the new trap-host option could
look like.  I realize I need to add better detail in the
final draft.  This list of configuration attributes is from
RFC 2573 appendix A, which lists trap configuration examples.
I'm assuming that in a DHCP environment, that the only address
domain supported is UDP.  I've also assumed that some other
configuration info must exist to make the security name
meaningful, but that this information does not belong directly
in a list of notification hosts, and might be placed in some
other, more general SNMP configuration option.

snmp-notification-list option is a UTF-8 string consisting
of a comma-separated list of notification targets.  Each
notification target is a colon-separated list of parameters
in the following order:


<proc-model> is a decimal field which must match one of the
message processing model values defined in RFC 2571 in the
SnmpMessageProcessingModel TC:

   0 - SNMPv1
   1 - SNMPv2c
   2 - SNMPv2u and SNMPv2* (I'm not sure what this is for)
   3 - SNMPv3


   This is the IP address and UDP port number of the target.  I
   wouldn't expect anyone to set up SNMP notifications over a non-IP 
   protocol such as OSI or DDP using DHCP, so I didn't include a domain.
   We could add it back in if there's good reason.

   IPv4 addresses are specified as dotted decimal with optional port:



   with the "/port" optional.

   IPv6 addresses are specified as a bracketed hexadecimal address,
   as specified in RFC2732, followed by the optional "/port".

   Example: [1080:0:0:0:8:800:200C:417A]/162.

<security-params> is optional and depends on the processing model used.

For v1 and v2c, this consists of a community string

<community-string> - The community string to use when sending
   notifications to this target.  If not specified, the default
   is "public".

For v3, this specifies the security model and its paramters, and
consists of:



   This is the security model number from the RFC 2571 SnmpSecurityModel
   TC.  The current (decimal) values are:

   1 - SNMPv1
   2 - SNMPv2c
   3 - User-Based Security Model (USM)


   This is the decimal security level number as specified in the RFC 2571
   SnmpSecurityLevel TC:

   1 - noAuthNoPriv
   2 - authNoPriv
   3 - authPriv


   This is the UTF-8 security name to be used with notifications to this


   A group of two v3 targets, both using USM with authentication but no


   A single v3 target, using USM with both authentication and privacy:


   A single address that wants both v1 and v2c notifications with the
   default community string and UDP port:


   An SNMPv2 address that uses a different community string:


BTW, using 0 for v1, 1 for v2c, and 3 for v3 is confusing, and these
strings have to be typed in by DHCP adminstrators.  We could go with
text tags "v1", "v2c", and "v3" instead for message processing
models, and allow "usm" for the security model as well:


Any preferences?
dhcwg mailing list