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

Re: Open/Closed Issues on SNMP Extended Protocol MIB




>>>>> 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> 
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.)

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<schoenw@ibr.cs.tu-bs.de>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>