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

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

[ in reply to comments/review <draft-ietf-ops-mib-review-guidelines-00.txt> ]

On Fri, 7 Feb 2003, Wijnen, Bert (Bert) wrote:
> - sect 3.7
>   I personally have no problem [if a to-be] IANA-maintained
>   MIB module stays in an RFC where it gets first published
>   and handed to the RFC-Editor. As long as it makes clear
>   that current versions should be picked up from the iana
>   web pages, and that furture revisions will NOT include
>   the current or updated revisions.
>   RFC1573 is an example of that for IANA ifTypes.

I am aware that RFC 1573 did not remove the IANAifType-MIB module,  
but that was the first time an IANA-maintained MIB module was
defined, and it should not be used as a precedent if we've since   
found a better way to do things.  I believe that the method used
for RFC 2932 is a better way, and for that reason I've cited it
as the best current accepted practice.

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.

Regards,

Mike