[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
adding suggested naming conventions for extension modules
On Sat, 5 Jul 2003, C. M. Heard wrote:
> JS> m) Appendix E says something about MIB module names. I suggest to add
> JS> one or two additional sentences which suggest that related MIB
> JS> modules and MIB module extensions should use the naming scheme
> JS> FOO-MIB, FOO-<EXTENSION>-MIB, ... rather than FOO-MIB,
> JS> <EXTENSION>-FOO-MIB, ... with the rationale that grouping all
> JS> related MIB modules below a common prefix makes it easier to find
> JS> them if you sort the module names alphabetically (on Unix "ls
> JS> FOO*").
> BW> Agreed
> OK by me.
It sounded good in the abstract until I remembered that we'd
already had this discussion once before in the thread entitled
"Naming Conventions for Descriptors (was: comments/review
On Fri, 21 Feb 2003, C. M. Heard wrote, in message
> JS> Looking at the OPT-IF-MIB, I actually tend to dislike the
> JS> module naming convention. I believe that if should be called
> JS> IF-OPT-MIB rather than OPT-IF-MIB since it actually seems to
> JS> be an extension of the IF-MIB for optical interfaces. I
> JS> generally prefer if the most general part of a module name is
> JS> first.
> That sounds odd to me, and apparently many folks agree ... the
> only (published) MIB modules I could find with names of the form
> IF-* are
> while other hand, there are a few of the form *-IF-*
> and many others that don't have -IF- in the name but do have the
> a prefix indicating the name of the technology (EtherLike-MIB,
> DS1, DS3, SONET, and so on). I think putting the name of the
> specific technology first (CIRCUIT-*, DOCS-*, DOT12-*, OPT-*) is
> a very defensible convention for the media-specific extentions
> to the IF-MIB (it would not have been a good idea for the
> inverted stack table MIB module, of course).
> Since I am doubtless annoying everyone else with this
> conversation perhaps I had better close it off by suggesting
> that we had better leave the guidelines vague on the selection
> of a prefix for a MIB module name since we apparently can't
> aways agree among [ourselves] on the best way.
Based on the above, I don't think it's wise to make this change,
unless someone can generate some text that will capture the
difference between IF-INVERTED-STACK-MIB (to which I'd feel
comfortable applying the proposed convention) and CIRCUIT-IF-MIB,
DOCS-IF-MIB, DOT12-IF-MIB, or OPT-IF-MIB (for which I strongly feel
that this convention is not appropriate). Note that if we do
include this rule and apply it to the media-specific MIB modules as
Juergen suggests then we'll need to use a different example than
OPT-IF-MIB in Appendix E.