Subject: snmpconf Trap parameters in snmpSend

From: Steve Moulton <[email-masked]>
Date: Mon, 16 Jul 2001 11:34:50 -0400

Issue 50: Specifying trap type and enterprise OID in snmpSend for 
the Trap of SMIv1.

(Again, I am not unilaterally declaring this issue 50, just
continuing the numbering from where it left off on the issues list
and my previous submissions).

Currently there is no way to specify the trap type and enterprise
OID for Traps.  I would be perfectly happy to specify that
only V2trap(6)s be sent (and omit the Trap(4) operation 
entirely) , but I suspect that the community at large may object to this.

I propose one of the following approaches.

1  Add a different accessor function for sending v1 traps, with
   the associated generic-trap, specific-trap, and enterprise
   parameters.  The agent-addr parameter could either require an
   additional argument, or be intuited from an IP address from the
   agent.

   I don't really favor this. 

2  Specify that, when using the Trap operation with 
   snmpSend, that the supplied parameters should follow
   V2Trap semantics, and automatically converted using the
   rules of rfc2576, section 3.2.

   I favor this approach, as it removes the need for adding 
   an accessor function for an exception case.

Possible text for approach 2:

If a SNMP Version 1 trap is requested (the opcode is 4 or Trap), 
then SNMP Version 2 trap parameters are supplied and converted
according to the rules of [RFC2576] section 3.2.  The first
variable binding must be sysUpTime.0, and the second must
be snmpTrapOID.0 [RFC1905, section 4.2.6].  Subsequent variable
bindings are copied to the SNMP Version 1 trap PDU in the
usual fashion.

---
Steve Moulton        SNMP Research, Inc            voice: +1 865 573 1434
Sr Software Engineer 3001 Kimberlin Heights Rd.    fax: +1 865 573 9197
[email-masked]     Knoxville, TN 37920-9716 USA  http://www.snmp.com

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 16 Jul 2001 16:51:28 -0700

>>>>> On Mon, 16 Jul 2001 11:34:50 -0400, Steve Moulton <[email-masked]> said:

Steve> 1  Add a different accessor function for sending v1 traps, with
Steve> the associated generic-trap, specific-trap, and enterprise
Steve> parameters.  The agent-addr parameter could either require an
Steve> additional argument, or be intuited from an IP address from the
Steve> agent.

Steve> I don't really favor this. 

Steve> 2 Specify that, when using the Trap operation with snmpSend,
Steve> that the supplied parameters should follow V2Trap semantics,
Steve> and automatically converted using the rules of rfc2576, section
Steve> 3.2.

Steve> I favor this approach, as it removes the need for adding an
Steve> accessor function for an exception case.

FYI, this is functionally what the net-snmp API does (as well as many
other APIs, I suspect) and we end up supporting both the "I'm sending
a v1 trap" and "I'm sending a v2 trap" and they both get automagically
converted (when possible).  However, if I were to pick one (which I
think SHOULD be done for snmpconf for simplicity purposes) I'd say go
with specifying v2 traps and having them get automatically converted
to v1 if the CR/NR in question supports v1 trap generation.
-- 
Wes Hardaker
NAI Labs
Network Associates

---

From: Jon Saperia <[email-masked]>
Date: Thu, 19 Jul 2001 08:33:26 -0400

Two comments: Steve M. thanks for posting these points they are helpful.
> to v1 if the CR/NR in question supports v1 trap generation.

By you last sentence you mean what by CR/NR. Is it not true that the
node will be configured to genererate the appropriate trap or inform to
the correct destinations based on the agent configuration? What am I
missing?

> Network Associates

Thanks,
/jon
--

Jon Saperia		     [email-masked]
			     Phone: 617-744-1079
			     Fax:   617-249-0874
			     http://www.jdscons.com/

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 19 Jul 2001 17:18:06 -0700

>>>>> On Thu, 19 Jul 2001 08:33:26 -0400, Jon Saperia <[email-masked]> said:

>> However, if I were to pick one (which I think SHOULD be done for
>> snmpconf for simplicity purposes) I'd say go with specifying v2
>> traps and having them get automatically converted to v1 if the
>> CR/NR in question supports v1 trap generation.

Jon> By you last sentence you mean what by CR/NR.

CR = command responder
NR = command generator

Jon> Is it not true that the node will be configured to genererate the
Jon> appropriate trap or inform to the correct destinations based on
Jon> the agent configuration? What am I missing?

Yes, that's what I'd expect.

However, this brings up another point.  Are you allowed to specify
where the TRAP PDU is sent to, or are you only allowed to tell the
host the script is running on "send this trap" and it's up to the
entity in question to send it to it's list of configured receivers.  I
could see arguments advocating one, the other, and both.
-- 
Wes Hardaker
NAI Labs
Network Associates

---

From: Jon Saperia <[email-masked]>
Date: Fri, 20 Jul 2001 17:26:22 -0400

> could see arguments advocating one, the other, and both.

If I were to argue, I would say we have an infrastructure to the
defintion of where notifcations go and whether they should be traps or
informs.  I see no compelling reason to invent a new one.

Thanks,
/jon
--