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

Re: Protocol operations proposal deadline




> [much discussion deleted surrounding extensibility and option negotiation]

> My take on this whole discussion is that:  You're both right.
> There is a fine line to be walked....

> Yes, I think it's generally agreed that more flexibility in the PDU
> structure would be a good thing at this point, but we must be
> cautious.

I'm concerned that my desire for flexibility might end up derailing
your object-oriented approach - so how about the following proposal.

The basic PDU format defined for SNMPv4 (or whatever we decide to
call it) could look something like:

     PDU ::=
         SEQUENCE {
             request-id
                 Integer32,
             error-status
                 INTEGER,
             error-index
                 INTEGER,
             error-description
                 OCTET STRING,
             options
                 OCTET STRING,
             variable-bindings
                 VarBindList
         }

(where VarBindList is defined suitably to cope with both existing protocol
operations and the new object-based requests).
  But the semantics of the individual bits of the 'options' field are left
undefined for now.  (Or probably some "fallback semantics" are defined,
leaving the door open for making use of this field later).

  That would allow the object-based proposal to go forward without undue
delay, and lay the framework for developing other extensions at a later date.
It's a bit of an overhead, but only two octets (which in the context of
the full SNMPv3 structure, isn't exactly significant!)

That drops some of the detailed flexibility of my original proposal
(and of the "extended error reporting" draft) - but I get the impression
that working at a whole-PDU level is generally regarded as a more
sensible option.


Dave