Now I'm hearing you say what I'm saying, that is good, but we're not
On Thu, Oct 23, 2008 at 09:41:49AM -0700, Randy Presuhn wrote:
Spectacularly bad design. It would make much more sense to only
ask for the interfaces of interest (if known) in the first place, and in
any case, asking for the individual variable bindings one at a time
is just silly, if you'll pardon the harsh language.
If a DHCP relay knew what leases were present in a DHCP server before
it issued a single SNMP packet, and of them which specific ones it
needed to know about, then it probably wouldn't need to issue an SNMP
packet at all.
Now you see the conundrum. The process to use SNMP to meet
leasequery's ends (to find out what leases it needs to query about,
and then finally also do that) would be to use SNMP in precisely the
way we are both saying is idiotic!
I have to agree completely and wholeheartedly: SNMP is just broken
for this use case.
The requirement for ordering is inherent in the protocol, and I agree
it makes interfacing with, e.g., an underlying SQL infrastructure (for
which "ordering" entails extra processing) a pain. But the point is
that deciding which indexes to use needs to be driven by management
use cases, in order to minimize the situations in which one would need
to walk through an entire table to find the useful bits.
There simply is no usable index. There is no database in our DHCP
implementation that is consistently sorted no matter what time (over
the runtime) you query it; in order to support GETNEXT to be able
to walk the various "lists of leases" and allow the clients to perform
the required discovery, we would have to change literally everything,
and vastly complicate our software.
It is work all around to shoehorn SNMP into this picture, for the
client, for the server, for everyone.
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/
David W. Hankins "If you don't do it right the first time,
Software Engineer you'll just have to do it again."
Internet Systems Consortium, Inc. -- Jack T. Hankins
Description: PGP signature
Ietf mailing list