adding suggested naming conventions for extension modules

["C. M. Heard" <heard@pobox.com>]

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
<draft-ietf-ops-mib-review-guidelines-00.txt>)":

On Fri, 21 Feb 2003, C. M. Heard wrote, in message
<Pine.LNX.4.10.10302210856001.18599-100000@shell4.bayarea.net>:
> 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
> 
> IF-MIB
> IF-INVERTED-STACK-MIB
> 
> while other hand, there are a few of the form *-IF-*
> 
> CIRCUIT-IF-MIB
> DOCS-IF-MIB
> DOT12-IF-MIB
> 
> 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.

Mike