From: Eric M. <er...@je...> - 2012-07-26 03:18:34
|
On 2012-07-23 08:01, Ingen Schenau, Jeroen van (ICTS) wrote: > Hi all, > > Over the last couple of weeks I have updated added and updated some > MIBs > and others have contributed to this part as well (notably Eric). In > this > process I've learned some new things about net-snmp and MIBs in > general. > > I've spent some time to minimize the number of changes in > mib_index.txt > and .index files, but now I've started to wonder: why do have the > .index > files in the repository anyway? If a user runs snmptranslate > manually, > the .index is usually (re)generated and in a different order than how > we > keep it in the repo. I don't really see any added value in including > the .index files; shouldn't we just drop them from the repository? > > And another subject I've been thinking about: IMHO it would be useful > to > not only have diffs of the MIB files, but also generate a full tree > of > objects as net-snmp has parsed after reading all our MIBs. This makes > it > a lot easier to see what objects have been added or removed, > especially > if objects were moved from one file to another. > > For example: after a question on IRC about a couple of Netscreen > devices > that didn't appear with a fully translated product name, I looked for > an > updated version of the Netscreen MIBs. I don't know how old the > current > set of MIBs is, but the most current Netscreen MIBs (from Juniper's > web > site) all have different names and there are more of them. I wouldn't > want to compare each file individually; I'd like to replace all files > with the new ones and then check the diff in output of eg > "snmptranslate > -Tt" & "snmptranslate -Tz" before and after the update, so I can > immediately check which objects have changed, without having to > bother > about what definition comes from what file, which whitespace or > comments > have changed, etc. > > What do you guys think? Would it be a good idea to drop the .index > files > from the repo, and would it be a good idea to update mkindex and have > it > generate a full MIB tree that we can compare for each commit? Or does > anyone have a better idea how we can get better insight in the > changes > that result from updating MIB files? I agree that we could / should remove the .index files from the repo. The packaged file excludes them, they will get auto generated. In the recent changes I followed the instructions in the UPGRADE file, this was adequate for my needs. The translate might run into some issues when running over the entire set of MIBs. There are already some unique cases where OID's are redefined in different MIB files in the enterprise space. Thanks, Eric |