On Mon, Jan 15, 2018 at 10:15 PM, Bart Van Assche <bvanass...@acm.org>
wrote:
> On 01/15/18 18:32, Fulko Hew wrote:
>
>> Yes, you could, but...
>>
>> If the definition of the trap doesn't include the fields that you want,
>> you are not (technically) allowed to add them.
>>
>> This is important because the receivers are designed to expect what
>> the definitions (in the MIB files) specify. No more, no less, and in
>> the order defined.
>>
>
> Hello Fulko,
>
> Can you provide a reference to a standard that backs your claim that it is
> not allowed to include more varbinds in a trap than specified in the
> corresponding MIB?
>
> I think that RFC 1902 suggests the opposite, namely that any additional
> number of varbinds may be included in a trap. From
> https://tools.ietf.org/html/rfc1902:
>
> 8.1. Mapping of the OBJECTS clause
>
> The OBJECTS clause, which need not be present, defines the ordered
> sequence of MIB object types which are contained within every
> instance of the notification. An object type specified in this
> clause may not have an MAX-ACCESS clause of "not-accessible".
a) I've always read that as saying that:
1/ a trap can be sent with zero objects (ie. missing OBJECTS clause),
and
2/ when objects are present, it defines the sequence of objects
and their mandatory order.
I would counter your question with my own:
Can you provide a reference that says a defined trap can be sent
without the objects also being defined.
I consider the spec... ambiguous in this regard.
b) I've always considered David Perkins' book 'Understanding SNMP MIBs'
as a good reference on how to interpret the specs.
For TRAPS it says: The optional VARIABLES clause of the TRAP-TYPE construct
is used to specify one or more scalar or columnar objects that describe the
event."
So if no variables describe the event, the the VARIABLES clause is
optionally present, and one would have to assume that if it was present,
it would be empty. i.e. VARIABLES {}
But if objects describe the event, then the VARIABLES clause is no longer
optional, but present because its needed to contain that sequenced list
of objects.
I.e. If the list defines the sequence of the objects, how can the list be
optional?
For NOTIFICATION-TYPE it says: The optional OBJECTS clause of the
NOTIFICATION-TYPE
construct is used to specify one or more scalar or columnar objects whose
values
describe the event. A single instance of each object type (and its value)
specified
in the OBJECTS clause is contained in an event report message.
----
So I say (IMHO) that how can you send a trap with variables (where the order
needs to be defined), without specifying what the variables are (and their
order).
My (40 years) experience would say, "don't send something that doesn't
match the spec"
(i.e. good engineering practice)
because if its not defined, how would anyone know what was being sent, why
it
was sent, and what it means to a receiver?
_I_ would consider it 'bad style', to send something that was ... not
documented in the MIB.
Fulko
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
