Re: guidelines section 3.7 (disposition of IANA MIB modules)

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

On Tue, 11 Feb 2003, Randy Presuhn wrote:
> If the IANA URL and "health warning" are provided, those who
> fail to follow it to get the current version of a MIB module have
> only themselves to blame if they use an earlier version from an
> RFC or I-D.

True, but we don't need to encourage such behaviour.

> I think the initial version of such a MIB *should* be published in
> an RFC.  As an example, I'd cite the "probable cause" stuff in
> the disman alarm work.  The benefits to publication of the initial
> revision in this case include:
>     1) "seeding" the initial set of supported values (which in this
>          case is quite large);
>     2) ensuring that the DESCRIPTION semantics are available
>          in the same document as their (primary) user;

And for the same reasons, you would presumably advocate putting a
snapshot of the then-current IANA MIB in updated RFCs?

>      3) making sure that it is all seen during the WG and
>          IETF last calls.

Having the IANA MIB in a removable appendix in the I-D (as
recommended in the current guidelines draft) will ensure
that this happens.  Leaving it the published RFC has no
bearing on last calls, since they will have long-since passed.

> Whether it should go into an appendix or not depends on the
> logical structure of the specification, something which we shouldn't
> be second-guessing here [ ... ]

If it's going to be removed in subsequent versions of the RFC (as
was done for the IF-MIB), it is not unreasonable to require (or at
least to recommend) that document authors plan for it.  Having such
requirements/recommendation is not new;  the guidelines for RFC
authors (2223bis) and the I-D nits document have several requirements
of that nature.

//cmh