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

RE: Open/Closed Issues on SNMP Extended Protocol MIB



hi

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

Juergen> I don't think that I said this. What I said is that SNMPv3 is not
Juergen> appropriate. We are talking about different versions of the
protocol
Juergen> operations (PDUs) and not different versions of the whole protocol.
Juergen> We have RFC 1905 operations (a revised version of this is going to
Juergen> full standard) while EOS is working on the next version of protocol
Juergen> operation - which will be the 3rd version of the protocol
operations
Juergen> - and not the protocol. 

When you start talking about bits on the wire, which is where my concern
lies, isn't it all the same thing?

Case 1: Can't set object using traditional sets ((plan A)/(plan B))


               notWritable/GenErr +-----------------------+
                     +------------+SNMP Manager supporting|
                     |            |RFC1905                |SNMPv3
                     |            +-----------------------+
       +-------------+---------+
       | SNMP Entity Supporting|
       | Enhanced RFC1905
       |                       |
       +-------------+---------+
                     |
                     |                +-------------------------+
                     |                | SNMP Manager Supporting |
                     +----------------+ Enhanced RFC1905        | EOS
                                      +-------------------------+
              notWritable/tooComplex


Case 2: Can't set object using EOS sets ((plan A)/(plan B))


             Not Applicable       +-----------------------+
                     +------------+SNMP Manager supporting|
                     |            |RFC1905                |SNMPv3
                     |            +-----------------------+
       +-------------+---------+
       | SNMP Entity Supporting|
       | Enhanced RFC1905
       |                       |
       +-------------+---------+
                     |
                     |                +-------------------------+
                     |                | SNMP Manager Supporting |
                     +----------------+ Enhanced RFC1905        | EOS
                                      +-------------------------+
              notFooWritable/notWritable

Juergen> Let me clarify you text:

Juergen> RFC1905 can't do arbitrary complex basic writes: genErr
        can't do eos writes: asn1ParseErrs (or perhaps unknownPduHandlers)

Juergen> What I am saying is that implementations right now return genErr in
Juergen> cases where they really would like to return a tooComplex, but
which
Juergen> does not exist. 
Juergen> I also argue that adding such an additional error code
Juergen> is unlikely to break applications since they will most likely treat
Juergen> everything they do not understand as genErr anyway. 

Ah.  My thinking is that they are currently returning notWritable for
things which they find too complicated to support via traditional sets.
GenErr then provides me less information than the current error message.

Juergen> So my suggestion
Juergen> was to add tooComplex in the 3rd version of the protocol operations
so
Juergen> that it can be used to reject set operations that do not map to row
Juergen> operations if my (sub-)agent only supports row operations. This
does
Juergen> not destabalize RFC 1905 and its revision.

Well, my preference is to get the same error code for not supporting
traditional
sets in SNMPv3 and EOS, and preferably without sending SNMPv3 a message they
will
end up dropping on the floor (mapping to GenErr).

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

Juergen> I have problems with this usage of notWritable. My interpretation
of
Juergen> the value notWritable is that it serves as an indication that an
Juergen> object can not be modified - regardless how hard the management
Juergen> application tries. So returning notWritable in response to a set 
Juergen> while being able to change an object via a row operation may 
Juergen> confuse implementors and applications. What I was suggestion is:

Juergen> EOS can't do arbitrary complex basic writes: tooComplex
Juergen>     can't do eos writes: notFooWritable (or something like that)

That does make some sense, but I still have some concerns:
	1. The 1905 compatibility I mentioned above
	2. I'm not sure if the fact that the operation is too complex
	   is the relevant part, or if the fact you can't do a set via
	   this method is.  Something like wrongMethod, invalidMethod,
	   or setXOnly would seem more appropriate if we were to go this
         route.

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.

Juergen> I do not see this extra layer. Perhaps the difference is my
assumption
Juergen> that the new protocol operations document will finally be called
Juergen> "Version 3 of the Protocol Operations for the Simple Network
Juergen> Management Protocol" and define all operations provided by the 3rd
Juergen> revision of the SNMP protocol operations in one place (including
Juergen> potentially slightly updated versions of the RFC 1905 operations).

But if SNMPv3 implementations don't support this new version, then we need 
to consider both versions.

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.

Juergen> Unfortunately, there is no version number for the protocol
operations.
Juergen> You can use new tags to get around this or the WG can just agree
that
Juergen> adding a new error code such as tooComplex to the existing set
Juergen> operation does not really cause interoperability problems with real
Juergen> management applications. (There might be warnings generated by
Juergen> protocol testers that try to be strict - but this is something I
can
Juergen> easily live with.)

If we can get the same result while keeping to error codes SNMPv3 friendly,
all the better.

Sharon