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

Re: Open/Closed Issues on SNMP Extended Protocol MIB


Juergen - your response makes perfect sense to me.

The unfortunate thing is the tags for version 1 of the protocol operations
were reused (except for traps) in version 2 of the protocol operations.
This caused a HACK in the SNMPv3 documents, and it looks like it has
confused Sharon.
The proper thing to do, which Juergen suggests, and I support is when
updating the protocol operations, to use NEW tags for the operations
that have different semantics!!

At 04:48 PM 7/3/2001 +0200, Juergen Schoenwaelder wrote:

>>>>>> Sharon Chisholm writes:
>Sharon> So you said:
>Sharon> SNMPv3 can't do basic writes: GenError
>Sharon>        can't do Foo writes:
>Sharon> EOS    can't do basic writes: tooComplex
>Sharon>         can't do Foo writes: notWritable
>I don't think that I said this. What I said is that SNMPv3 is not
>appropriate. We are talking about different versions of the protocol
>operations (PDUs) and not different versions of the whole protocol.
>We have RFC 1905 operations (a revised version of this is going to
>full standard) while EOS is working on the next version of protocol
>operation - which will be the 3rd version of the protocol operations
>- and not the protocol. Let me clarify you text:
>RFC1905 can't do arbitrary complex basic writes: genErr
>        can't do eos writes: asn1ParseErrs (or perhaps unknownPduHandlers)
>What I am saying is that implementations right now return genErr in
>cases where they really would like to return a tooComplex, but which
>does not exist. I also argue that adding such an additional error code
>is unlikely to break applications since they will most likely treat
>everything they do not understand as genErr anyway. So my suggestion
>was to add tooComplex in the 3rd version of the protocol operations so
>that it can be used to reject set operations that do not map to row
>operations if my (sub-)agent only supports row operations. This does
>not destabalize RFC 1905 and its revision.
>Sharon> And I said:
>Sharon> SNMPv3 can't do basic writes: notWritable
>Sharon>        can't do Foo writes: 
>Sharon> EOS    can't do basic writes: notWritable
>Sharon>         can't do Foo writes: notFooWritable
>I have problems with this usage of notWritable. My interpretation of
>the value notWritable is that it serves as an indication that an
>object can not be modified - regardless how hard the management
>application tries. So returning notWritable in response to a set 
>while being able to change an object via a row operation may 
>confuse implementors and applications. What I was suggestion is:
>EOS can't do arbitrary complex basic writes: tooComplex
>    can't do eos writes: notFooWritable (or something like that)
>Sharon> So, it seems that I am suggesting protocol level error codes,
>Sharon> and yours are one layer above that. I'm not sure which are
>Sharon> best.
>I do not see this extra layer. Perhaps the difference is my assumption
>that the new protocol operations document will finally be called
>"Version 3 of the Protocol Operations for the Simple Network
>Management Protocol" and define all operations provided by the 3rd
>revision of the SNMP protocol operations in one place (including
>potentially slightly updated versions of the RFC 1905 operations).
>Sharon> Oh, wait.  If we are talking basic set operations, can be ever
>Sharon> tell the difference between SNMPv3 sets and EOS sets?  I
>Sharon> suspect we can't.
>Unfortunately, there is no version number for the protocol operations.
>You can use new tags to get around this or the WG can just agree that
>adding a new error code such as tooComplex to the existing set
>operation does not really cause interoperability problems with real
>management applications. (There might be warnings generated by
>protocol testers that try to be strict - but this is something I can
>easily live with.)

/david t. perkins