[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Open/Closed Issues on SNMP Extended Protocol MIB
Sharon> Ah. My thinking is that they are currently returning
Sharon> notWritable for things which they find too complicated to
Sharon> support via traditional sets. GenErr then provides me less
Sharon> information than the current error message.
Juergen> I do not think RFC 1905 says that. My reading of RFC 1905 is that
Juergen> requires you to handle arbitrary combinations of objects in a set
Juergen> operation. The notWritable returns in section 4.2.5. of RFC 1905
Juergen> all on a per varbind basis. RFC 1905 does not have a tooComplex
Juergen> code - something well known to people who have been involved in
Juergen> some longer time (there were already tons of bits wasted on this in
Juergen> the past - so the problem is well known but was never addressed).
Juergen> Perhaps some implementations do return a notWritable and perhaps
Juergen> implementations do return a genErr in cases they know they can't
Juergen> handle. I can imagine that some perhaps even claim a commitFailed.
Juergen> these different interpretations exist, then this would be clear
Juergen> to me that this really needs to get fixed.
We started out talking about the much simpler question of allowing
to support eos sets without supporting traditional sets (POv2). It sounds
like you are
now suggesting the support of traditional sets (POv2) with the same
eos sets (POv3)put on them and returning "tooComplex" when the
implementation can't handle
what is sent. I don't know if we want to allow that. If we do, then your
code does make sense.
I am assuming the restrictions that EOS sets (POv3) will put on the
operations like order
and complete information will be somewhat obvious to someone formulating a
on how the new operations are defined. We can't really go back and do that
sets. If we could, we would not need the new row operations (efficiency
1. Support traditional sets with all the flexibility/complexity it
currently has (POv2), plus eos sets (POv3)
2. Support traditional sets without the flexibility/complexity and
return "tooComplex" (POv3)
The two challenges for Option 2, would be (yes, I like making lists):
1. Making sure restrictions can be somewhat determined ahead of time
2. Compatibility with POv2
If we can overcome those challenges and then add OID suppression or
something, then that would
be great. If we can't, then we probably want to leave traditional sets alone
on new operations.
Although, option 2 is kind of interesting. What percentage of the problem
would get solved by
a fooRowStatus without CreateAndWait and which forces operations with all
table columns and
all objects in their column order?