[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: guidelines section 3.7 (disposition of IANA MIB modules)
Hi -
> From: "C. M. Heard" <heard@pobox.com>
> To: "Mreview (E-mail)" <mreview@ops.ietf.org>
> Sent: Tuesday, February 11, 2003 11:38 AM
> Subject: Re: guidelines section 3.7 (disposition of IANA MIB modules)
....
> Let me explain my reasoning. In general, I think it's better
> NOT to publish unauthoritative versions of an IANA MIB module
> (or anything else) in an RFC, because people tend to extract
> the unauthoritative version from the RFC instead of getting
> the latest one from IANA. Furthermore, the IANA MIB module
> will normally be removed from future versions of the spec (e.g.,
> IANAifType-MIB was not included in RFC 2233 or RFC 2863). It
> seems inconsistent to include a snapshot of the IANA MIB in
> the initial RFC but not in subsequent revisions.
>
> If you don't agree with this reasoning I guess we need to
> discuss the issue further. At the very least, if the initial
> version of an IANA MIB module is included in an RFC, then it
> needs to be put into an appendix (so it is easy for authors
> of future revisions to remove it), and that appendix should
> be clearly marked as non-normative. It's much better, in my
> view, just to leave it out of the published document and
> include the IANA URL.
...
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.
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;
3) making sure that it is all seen during the WG and
IETF last calls.
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, but it should certainly be normative.
(If it's non-normative, what's the point of publishing it?)
Randy