[sr-dev] SNMPstats module

Olle E. Johansson oej at edvina.net
Thu Oct 1 13:56:48 CEST 2009


27 sep 2009 kl. 22.10 skrev Olle E. Johansson:

>
> 27 sep 2009 kl. 22.06 skrev Olle E. Johansson:
>
>> SNMPstats currently lives in modules_k. As we've got an OID for Kamailio.org 
>>  it's time to update the module.
>>
>> 1. Change the OID - maybe with a config option if people depend on  
>> the old
>>
>> 2. Change file names on all files starting with "openser". I don't  
>> see why we need a name tag in these file names. Anyone else?
>>   openserObjects.h could very well be snmpObjects.h
>>
>> 3. Update all MIBS so that we don't use the openser namespace or  
>> OID. I would suggest that we change all "openser" tags to  
>> "siprouter" to enable this module to move in to core at some point.  
>> Changing MIBs to have "kamailio" in all names doesn't seem very  
>> long term for me.
>>
>
> Maybe we should consider using the common SIP mib for where we  
> follow it and only use Kamailio/Sip-router specific mibs for extras.  
> I think our MIBS was created at a very early stage of the SIP mibs.  
> Anyone that knows more about this and have comments?
>
> Looking from my newbie perspective I don't see any reason on why we  
> should in large parts copy the standard MIB and still use our own  
> definitions.

Daniel,
Thanks for the commits. I think you failed to read the part where I  
said "I can start working on this" ;-)

I still want to have a discussion about the last part above - why are  
we not using the standard SIP mib where we can?

Also, maybe we should reorganize the mib so that we suballocate for  
future use outside of snmp

	kamailiooid.10    SNMP
	kamailiooid.20	LDAP

Right now I believe we're using the full OID directly for snmp  
subclasses.

Anyone that has experience of organizing OID trees that can give some  
input?

We can't change it in every release, as we will propably break  
existing scripts and management platforms, so we will have to try to  
do it right while we're messing with it :-)

/O



More information about the sr-dev mailing list