[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Recommendation on the path forward for EOS


I think that Juergen's memory is a little cloudy on the issue below...

First, there is absolutely no need to change the version of the 
message as long has the fields are the same. That is, as long as
the message is in the format as specified in RFC 2572, which is
      SNMPv3Message ::= SEQUENCE {
           -- identify the layout of the SNMPv3Message
           -- this element is in same position as in SNMPv1
           -- and SNMPv2c, allowing recognition
           -- the value 3 is used for snmpv3
           msgVersion INTEGER ( 0 .. 2147483647 ),
           -- administrative parameters
           msgGlobalData HeaderData,
           -- security model-specific parameters
           -- format defined by Security Model
           msgSecurityParameters OCTET STRING,
           msgData  ScopedPduData
then there is no need to update the version or set bits, etc.
Of course, it might be nice to have an object with data type BITS
that specifies the PDU types supported. 

Secondly, RFC 2572 contains a mechanism that is used to report non-support
for "new" (or old) PDU types. That is, counter snmpUnknownPDUHandlers
is incremented and a report returned. This is a HORRIBLE name for
this event, but like Juergen, both of us fought the SNMPv3 chair and
authors and lost on this point. Also note that the counter is an
OR of two conditions. It seems bad, but support of PDU type is
typically not "dynamic", so if a management app gets a report on
the first attempt to use the PDU type, then it can probe to see
if the report was due to the context value or the PDU type, and
if the PDU type, remember that and don't try again. Again, it would
be very easy to add an object to indicate the supported types,
but it is not necessary. You just try each type and see if you
get back a report. (This worked for all currently defined PDU
types except v2Traps!)

At 05:44 PM 9/25/2002 +0200, Juergen Schoenwaelder wrote:
>>>>>> Dave Shield writes:
>Dave> One question:
>Dave> Is it intended that this would be a new PDU within the existing
>Dave> SNMPv3/v3MP framework, or would we be expecting to define a new
>Dave> version at some level (either SNMPv4 or SNMPv3/v4MP) ?
>I have not seen anybody who seriously proposed to invent a new message
>processing model. But I guess your question is which mechanism or bit
>we use to signal that one is sending new PDUs. This is certainly a
>question to think about. And even if the answer would be to toggle a
>bit in the SNMP version field, I still would not call that another
>message processing model. But I am not convinced we need to bump the
>version field at all.
>[BTW, several years ago I lost a battle to convince the SNMPv3 WG that
> we should have a report mechanism for unknown PDUs so that apps can
> simply try new ones without having to wait for a timeout...]
/david t. perkins