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

RE: Open/Closed Issues on SNMP Extended Protocol MIB


Juergen> Another option would be to redefine the RFC 1905 set operation so
Juergen> it allows implementors to return a tooComplex error code when they
Juergen> receive sets that try to modify multiple rows in multiple tables in
Juergen> ways that are hard to implement (e.g. do not map to row
Juergen> This way, I can implement row ops instrumentation and still support
Juergen> (potentially sufficient) subset of all possible set operations.

Juergen> My experience is that most existing management applications do not
Juergen> send arbitrarily complex sets because that won't work in practice.
Juergen> So the costs for handling a tooComplex error code in management
Juergen> applications if probably not very high - and you can map tooComplex
Juergen> to e.g. genErr for those old applications that expect RFC 1905
Juergen> semantics.

Juergen> I guess I argue for being able to map RFC 1905 operations to row
Juergen> instrumentations rather than mapping row ops operations to RFC 1905
Juergen> instrumentations with the goal to clearly cut the implementation
Juergen> on the agent side.

Adding "tooComplex" to 1905 means adding an error code to 1905 that SNMPv3
managers would see, but would not understand.  We could fix this by holding
up SNMPv3 and adding it, but I don't think that would go over very well.

What about returning "notWritable" in those cases, since this is what would
happen now.  We then can introduce a new error code which is
or something to be used specifically with the new PDU operations. The SNMPv3
manager would therefore never see this.

notWritable - This object is not setable via traditional sets
notNewWritable - This object is not setable via new sets

I think this might have to same sort of result, except be more backwards