On 12 September 2013 18:48, Reyk Floeter <r...@openbsd.org> wrote: > On Thu, Sep 12, 2013 at 06:28:15PM +0200, Mike Belopuhov wrote: >> > Sure, I do. You're trying to push one thing and you don't want to >> > hear the concerns about a specific detail of it. >> > >> >> with all respect, i think you don't. otherwise you wouldn't be asking >> the questions you're asking. >> >> we do hear your concerns, but since even before the change if_index >> was not static at all the way you seem to be implying snmp requires >> it, i don't see a situation drastically changing. if you create all >> the interfaces on startup or before you start snmpd and don't destroy/ >> re-create them nothing is changed. >> > > Ok, let's stop this. I don't think you read what I replied before. I > didn't say that we're static with if_indexes, just that we shouldn't > make it worse. >
or implement persistent indices in the snmpd itself maybe? > I give up, but please read my next comment below. > >> >> > Isn't there any other way to do what you want without stopping to >> >> > reuse the index? SNMP simply expects that if_indexes are fairly >> >> > static, linear, and without holes. Why should we change that in >> >> > OpenBSD? Is there any security reason to "randomize" the indexes - >> >> > No. >> >> >> >> or snmp can simply stop assuming things. if_index wasn't created >> >> for snmp in the first place. > > Actually, I think this assumption is wrong. I researched a little bit > in BSD history: > > - RFC 1066 from August 1988 is one of the early SNMP RFC that mention IfIndex > > - 4.3BSD-Tahoe from June 1988 doesn't have if_index, I also didn't find > in other early BSDs. > > - 4.3BSD-Reno from June 1990 does have it. You can even find a > new comment "/* XXX fast fix for SNMP, going away soon */" on top of if.h. > > So it seems that if_index was added _for_ SNMP. > i believe this comment refers to the inclusion of sys/time.h. >> > Of course, everyone else is wrong, let's change the world! IfIndex is >> > used by SNMP since at least 1988 (RFC 1066) and many many tools have >> > adopted it expecting this behaviour. Anyway, just go ahead and do the >> > stuff. I don't care, it is not a big issue for snmpd. But I still >> > don't see the point of changing the semantics instead of finding >> > another way to do what you want. Unless there is a security issue or >> > similar with if_indexes and changing it would actually improve >> > something. Blah. >> >> no need to get upset. mpi's change does improve things. we want to >> make full use of if_index' initial design and use it as a reference >> to the interface in the mp network stack . it has nothing to do with >> a badly designed protocol from the eighties. > > Oh, come on. SNMP is as badly designed as many other things that > we're using every day. sure. > Do you suggest to rm snmpd because the > protocol is badly designed? > no, i don't. i merely suggest that if_index should not be used if persistent ifindex'es are required.