Now I'm hearing you say what I'm saying, that is good, but we're not quite done; 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
Attachment:
pgp6FeqaGyUqE.pgp
Description: PGP signature
_______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf