RE: Module names and MIB names

["Sharon Chisholm" <schishol@nortelnetworks.com>]

Hi

I don't think it makes sense to equally enforce the rules we know are there
for a really good reason and the nice to have ones. Not only are there
diminishing returns, it divides focus, increasing the chances that we miss
something important while looking at something less so.

I propose we declare the appendix non-normative and focus enforcement on the
body of the document.

I agree we should at least try for the nice to haves and I've already
created editing instructions to add a -MIB to the module names in question. 

Sharon

-----Original Message-----
From: C. M. Heard [mailto:heard@pobox.com] 
Sent: Thursday, February 19, 2004 4:48 PM
To: Mreview (E-mail)
Subject: Re: Module names and MIB names


On Thu, 19 Feb 2004, Wijnen, Bert (Bert) wrote:
> The DISMAN WG has delivered 
>    draft-ietf-disman-alarm-mib-18.txt
> which includes two MIB Modules with just TCs.
> Their names are
> 
>    ITU-ALARM-TC
>    IANA-ITU-ALARM-TC
> 
> And the latest revision of smilint program flags it with a warning 
> that the module name does not have suffix of *-MIB. This is based on 
> our (MIB doctors developed) MIB review guidelines:
>   
>    draft-ietf-ops-mib-review-guidelines-02.txt
> 
> Specifically section 4.1 and appendix C.
> 
> Now.... this MIB document was developed by members of teh MIB Doctor 
> team and under a WG chair who is also in the MIB Doctor team. So this 
> does not feel right.
> 
> We as MIB doctors eat our own dogfood, or we remove such guidelines.

So far so good, I agree.

> So my question that I want answered by all MIB doctors is:
>   Do we keep this guideline or do we do away with it.
> 
> pls choose one of these two answers:
> 
>  - Do away with it. It is a CLR (Crappy Little Rule)
>  - Keep it. It is a CLR (Consistency Language Rule or
>    some such positive thing)

Before I answer let me point out that I carefully and deliberately worded
Appendix C as a _suggestion_ ... i.e., something that we think is a good
idea, but not something that we strive to enforce as strongly as something
marked with the capitalized keywords SHOULD or RECOMMENDED.  Here is what
the document actually says:

Appendix C:  Suggested Naming Conventions

   Authors and reviewers of IETF MIB modules have often found the
   following naming conventions to be helpful in the past, and authors
   of new IETF MIB modules are urged to consider following them.

   - The module name should be of the form XXX-MIB, where XXX is a
     unique prefix (usually all caps with hyphens for separators) that
     is not used by any existing IETF MIB module.  For example, the MIB
     module for managing optical interfaces [OPTIF] uses the prefix
     OPT-IF and has module name OPT-IF-MIB.

I think that _as a suggestion_ what Appendix C says is quite reasonable, and
I would like to keep it.  Remember, we put it in because we saw modules from
inexperienced MIB developers (MPLS WG if memory serves) that had names which
followed no discernible pattern.

On Thu, 19 Feb 2004, Randy Presuhn wrote:
> Do away with it, if folks are going to read the RECOMMENDED as a MUST.

I would have to agree with this ... HOWEVER, I don't think that it is
unreasonable to expect MIB Doctors to toe the mark a bit more strictly than
ordinary folk.  And that's why I agree with Bert that it does not feel right
to have the aforementioned DISMAN modules not following the suggestions in
Appendix C.  Indeed, I regret that smilint did not have a check for
compliance with these suggestions when I was editing ETHER-WIS ... that name
was inherited from an early draft, and I failed to change it to
ETHER-WIS-MIB owing to oversight.

> To me, a rule that says "the last four characters of all modules names 
> MUST be '-MIB'" is the epitome of a CLR in the pejorative sense.  For 
> it to be a RECOMMENDation seems perfectly reasonable, as long as there 
> is some consensus about the cases where it doesn't make sense.
> 
> However, we've done sillier things, so please don't get the impression 
> that I feel too strongly about this.

I agree completely with these statements.

Mike