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

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

On Tue, 11 Feb 2003, Randy Presuhn wrote:
> > On Tue, 11 Feb 2003, Randy Presuhn wrote:
> > > [ ... ] but it should certainly be normative.
> >
> > No, it _cannot_ be normative, because the version maintained by IANA
> > is.  There are never two normative version of the same thing.
> 
> No.  It *is* normative.  If it were not, we couldn't make
> normative references (e.g. IMPORTS) from other standards.  It
> will superceded if/when the IANA copy is updated.  That's what
> the "health warning" and IANA pointer are for.
> 
> If we label something as "non-normative", it means that the technical
> effect of the specification would be unchanged if that material had never
> existed, which is clearly not the case here.

But the effect of the technical specification IS unchanged if the
unauthoritative copies of the IANA-maintained MIBs are omitted from
the specification and the IANA pointer is all that is given.  Both
RFC 2932 or RFC 2863 do exactly that:  the IANA-maintained MIB modules
that they reference (IANA-RTPROTO-MIB and IANAifType-MIB respectively)
are absent from those documents.  Instead, they refer you to the
IANA web pages where you will find the mib modules (the URLS are
http://www.iana.org/assignments/ianaiprouteprotocol-mib and
http://www.iana.org/assignments/ianaiftype-mib respectively).

> > > (If it's non-normative, what's the point of publishing it?)
> >
> > My point exactly.
> 
> Perhaps I'm not being clear: marking something as "non-
> normative" means it is *NOT* part of the specification.

That's right.  We are completely in sync up to this point.

> Non-normative material is typically examples, use cases,
> and other "stuff" to help readers understand how to
> apply a standard.  These MIB modules are much more
> than "examples".

It's also used in certain specifications (IEEE 802.3ae is
an example) where that specification makes a normative
reference to some other specification (ANSI T1.416-1999, in
this case) as an authoritative source (in this case, for
definitions of fields in SONET frames) but includes in
informative text definitions found in the normative
references.  That, precisely, is what we are doing when we
provide a pointer to an IANA-maintained MIB module (which
is the authoritative version) and also put a copy of that
MIB module into our specification.

Readers of the RFC do NOT need to have a copy of the
IANA-maintained MIB module in the RFC because they can
always get the "real" one from the IANA web site.

If you are concerned with the procedures for "seeding"
the IANA-maintained MIB module, do please note that 
Section 3.7 of the guidelines tell you how to do that:
put it in an appendix, with a note to the RFC Editor
that the appendix is to be removed upon publication
(when the IANA module goes on-line).

As is obvious from the way I have been arguing, I happen
to deplore the practice of having informative text in
one spec that is a (possibly imperfect) copy of some
text that appears normatively in something else.  I tend
to believe that it's always better to have "one version
of the truth".

For whatever it is worth, the way that I prepared Section
3.7 was to look at some cases of recent practice and
document what I found.  It's possible that I stopped
looking before I should have because the practices that
I found happened to agree with my prejudices.

Regards,

Mike